Ticket #224 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

avahi-daemon segfaults on avr32 / buildroot

Reported by: mpfj Owned by: lennart
Milestone: Component: avahi-core
Keywords: Cc:

Description

Just trying to get avahi working on one of Atmel's AVR32 dev kits (NGW100) using the latest buildroot svn (which uses avahi 0.6.22).

avahi-autoipd appears to work out of the box, but several attempts to get avahi-daemon working all fail with a segmentation fault.

Attached is the console output I get.

Nothing appears to have come back with an error, so any ideas ?

Thanks Mark

Attachments

avahi-segfault.txt Download (6.0 KB) - added by mpfj 5 years ago.

Change History

Changed 5 years ago by mpfj

follow-up: ↓ 2   Changed 5 years ago by lennart

please provide a gdb backtrace!

in reply to: ↑ 1 ; follow-up: ↓ 3   Changed 5 years ago by mpfj

Replying to lennart:

please provide a gdb backtrace!

Hmmm ... that's *way* beyond my level of expertise ... sorry.

in reply to: ↑ 2 ; follow-up: ↓ 4   Changed 5 years ago by lennart

Replying to mpfj:

Replying to lennart:

please provide a gdb backtrace!

Hmmm ... that's *way* beyond my level of expertise ... sorry.

Hmm, I fear getting things to work on embedded hardware like AVR32 requires some expertise in that area. I am sorry, but I cannot help you without a bt because I lack the hardware for that.

It's actually pretty easy to get that backtrace:

  1. install gdb
  2. run gdb avahi-daemon
  3. type "r"
  4. wait until it crashes
  5. type "bt full"
  6. paste the output of that here.

in reply to: ↑ 3 ; follow-up: ↓ 5   Changed 5 years ago by mpfj

Replying to lennart:

It's actually pretty easy to get that backtrace: 1. install gdb 2. run gdb avahi-daemon 3. type "r" 4. wait until it crashes 5. type "bt full" 6. paste the output of that here.

Okay ... I get this:-

#0 0x2ab2fb28 in ?? () No symbol table info available. #1 0x2ab2fb40 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?)

... so I guess all the debug info has been compiled away ??

in reply to: ↑ 4 ; follow-up: ↓ 6   Changed 5 years ago by lennart

Replying to mpfj:

Replying to lennart:

It's actually pretty easy to get that backtrace: 1. install gdb 2. run gdb avahi-daemon 3. type "r" 4. wait until it crashes 5. type "bt full" 6. paste the output of that here.

Okay ... I get this:- #0 0x2ab2fb28 in ?? () No symbol table info available. #1 0x2ab2fb40 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) ... so I guess all the debug info has been compiled away ??

Seems so. Make sure to compile Avahi with -g -O0.

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 5 years ago by lennart

... so I guess all the debug info has been compiled away ??

Seems so. Make sure to compile Avahi with -g -O0.

Use this to achieve that:

CFLAGS="-g -O2" ./configure ....

and then rebuild with "make"

in reply to: ↑ 6   Changed 5 years ago by mpfj

Replying to lennart:

Use this to achieve that: CFLAGS="-g -O2" ./configure .... and then rebuild with "make"

Okay ... I've done this, but still no joy. GDB now outputs:- 

Remote debugging using 10.0.0.103:1024
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x2aaab884 in ?? ()
(gdb)

(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x2ab42b28 in ?? ()
(gdb) bt
#0  0x2ab42b28 in ?? ()
#1  0x2ab42b40 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

The "No symbol table info available" error has now gone so I guess I've compiled it correctly with debug support, but there's still no actual debug output ??

Any ideas ?

follow-up: ↓ 9   Changed 5 years ago by lennart

Hmm, the problem might be related to the fact that you do remote debugging. I have never done that, but the problem might be that you need the debug symbols on the client gdb's side not the server side. But quite frankly I have no idea. I think it would be best if you asked the gdb or avr32 communities for help!

in reply to: ↑ 8   Changed 5 years ago by mpfj

Replying to lennart: Okay .. I've got a bit further, but I'm not sure if this is any help ... 

(gdb) target remote 10.0.0.103:1024
Remote debugging using 10.0.0.103:1024
0x2aaab884 in _start ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/ld-uClibc.so.0
(gdb) list
1330	#ifdef HAVE_DBUS
1331	    config.enable_dbus = 1;
1332	    config.fail_on_missing_dbus = 1;
1333	#endif
1334	    
1335	    config.drop_root = 1;
1336	    config.set_rlimits = 1;
1337	#ifdef ENABLE_CHROOT
1338	    config.use_chroot = 1;
1339	#endif
(gdb) break main
Note: breakpoint 1 also set at pc 0x644a.
Breakpoint 2 at 0x644a: file main.c, line 1319.
(gdb) list
1340	    config.modify_proc_title = 1;
1341	
1342	    config.disable_user_service_publishing = 0;
1343	    config.publish_dns_servers = NULL;
1344	    config.publish_resolv_conf = 0;
1345	    config.use_syslog = 0;
1346	    config.debug = 0;
1347	    config.rlimit_as_set = 0;
1348	    config.rlimit_core_set = 0;
1349	    config.rlimit_data_set = 0;
(gdb) bt
#0  0x2aaab884 in _start ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/ld-uClibc.so.0
#1  0x00000000 in ?? ()
(gdb) cont
Continuing.
warning: .dynamic section for "/usr/lib/libavahi-common.so.3" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/usr/lib/libavahi-core.so.5" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/usr/lib/libexpat.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?)

Program received signal SIGSEGV, Segmentation fault.
0x2ab42b28 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
(gdb) bt full
#0  0x2ab42b28 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#1  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#2  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#3  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#4  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#5  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#6  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#7  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#8  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
#9  0x2ab42b40 in _pthread_cleanup_push_defer ()
   from /usr/local/dev/avr32/buildroot-avr32-v2.2.0-rc4/build_avr32/staging_dir/lib/libc.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---q
(gdb)

I have also found reference to another uclibc / avahi / pthread problem here  http://www.nabble.com/Re%3A-Debugging-VICE-emulator-for-AVR32-p17998550.html.

I will see If can use uclibc 0.9.28.3

  Changed 5 years ago by lennart

Hmm, avahi-daemon doesn't use any pthread calls except in avahi_elapse_time() inavahi-common/timeval.c. This really looks like some uclibc fuckup to me.

  Changed 5 years ago by mpfj

  • status changed from new to closed
  • resolution set to fixed

Okay ... after much head scratching, I decided to blow away my dev toolchain and start again.

Now it's different ... there's no segfault anymore :-)

But the daemon now fails to open the services files.

Since this is a new problem, I'll close this ticket, and raise another !!

Sorry for wasting anyone's time ...

Note: See TracTickets for help on using tickets.