net/avahi-app core dumps signal 11

[Dimitry Andric]

On 31 Jan 2014, at 16:50, Thomas Mueller <tmueller at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140131/d2f69645/attachment-0001.sig>