On 31 Jan 2014, at 16:50, Thomas Mueller <tmuel...@sysgo.com> wrote: > [current build] > nomad:/usr/ports/net/avahi-app# > ./work/avahi-0.6.31/avahi-utils/.libs/avahi-browse > Segmentation fault (core dumped) > > nomad:/usr/ports/net/avahi-app# size /usr/local/bin/avahi-browse > work/avahi-0.6.31/avahi-utils/.libs/avahi-browse > text data bss dec hex filename > 19584 1176 4488 25248 62a0 /usr/local/bin/avahi-browse > 19584 1176 4488 25248 62a0 > work/avahi-0.6.31/avahi-utils/.libs/avahi-browse > > Then there's a difference in the order of libraries in the ldd output, > but I don't know if that is relevant: > > nomad:/usr/ports/net/avahi-app# ldd /usr/local/bin/avahi-browse > work/avahi-0.6.31/avahi-utils/.libs/avahi-browse > /usr/local/bin/avahi-browse: > libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 > (0x800820000) > libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x800a2f000) > libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 > (0x800c82000) > libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x800e8e000) > libssp.so.0 => /lib/libssp.so.0 (0x801098000) > libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80129a000) > libthr.so.3 => /lib/libthr.so.3 (0x8014a3000) > libc.so.7 => /lib/libc.so.7 (0x8016c8000) > work/avahi-0.6.31/avahi-utils/.libs/avahi-browse: > libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 > (0x800820000) > libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x800a2f000) > libthr.so.3 => /lib/libthr.so.3 (0x800c82000) > libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 > (0x800ea7000) > libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x8010b3000) > libssp.so.0 => /lib/libssp.so.0 (0x8012bd000) > libintl.so.9 => /usr/local/lib/libintl.so.9 (0x8014bf000) > libc.so.7 => /lib/libc.so.7 (0x8016c8000) > > On a hunch, I downgraded devel/dbus back from 1.6.18 to 1.6.12, now the > resulting avahi programs no longer dump core.
Hmm, at least I can reproduce it, but the stack trace does not tell me that
much:
(gdb) run
Starting program:
/usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/./avahi-utils/.libs/avahi-browse
[New LWP 101263]
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 101263]
_thr_cancel_enter (curthread=0x0) at
/share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
141 curthread->cancel_point = 1;
(gdb) bt
#0 _thr_cancel_enter (curthread=0x0) at
/share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
#1 0x280d0f2d in __open (path=<optimized out>, flags=<optimized out>)
at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390
#2 0x280fef46 in __guard_setup () at
/share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72
#3 0x280ff182 in ?? () from /lib/libssp.so.0
#4 0x280fe749 in _init () from /lib/libssp.so.0
#5 0x00000000 in ?? ()
(gdb) up
#1 0x280d0f2d in __open (path=<optimized out>, flags=<optimized out>)
at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390
390 _thr_cancel_enter(curthread);
(gdb) up
#2 0x280fef46 in __guard_setup () at
/share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72
72 fd = open ("/dev/urandom", O_RDONLY);
E.g., __guard_setup() tries to get some random bytes from /dev/urandom
(probably for the stack canaries), libthr considers this to be a thread
cancellation point, but for some reason the current thread is zeroed
out? I don't think this is ever supposed to happen... :-)
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
