net/avahi-app core dumps signal 11

[Sergio de Almeida Lenzi]

Em Sex, 2014-01-31 às 22:57 +0100, Dimitry Andric escreveu:

> On 31 Jan 2014, at 21:35, Dimitry Andric <dim at FreeBSD.org> wrote:
> ...
> > 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... :-)
> 
> So avahi-browse gets linked as follows (wrapped a little for clarity): 
> 
> cc -I.. "-DDEBUG_TRAP=__asm__(\"int \$3\")"
> -DDATABASE_FILE=\"/usr/local/lib/avahi/service-types.db\" -O2 -pipe
> -march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall
> -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition
> -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations
> -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
> -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith
> -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
> -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing
> -o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o
> avahi_browse-stdb.o -L/usr/local/lib
> ../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so
> -lpthread
> /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so
> ../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp
> /usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib
> 
> This executable segfaults, and has the NEEDED libs in the following
> order:
> 
> .libs/avahi-browse:
>         libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
>         libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
>         libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
>         libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
>         libssp.so.0 => /lib/libssp.so.0 (0x28106000)
>         libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28109000)
>         libc.so.7 => /lib/libc.so.7 (0x28112000)
> 
> When I remove the -lssp from the above linking command line, it is
> automatically induced anyway, but the executable then gets the following
> NEEDED libs order:
> 
> .libs/avahi-browse:
>         libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
>         libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
>         libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
>         libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
>         libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28106000)
>         libc.so.7 => /lib/libc.so.7 (0x2810f000)
>         libssp.so.0 => /lib/libssp.so.0 (0x28263000)
> 
> E.g. libssp.so.0 is now located at the end of the list.  And _this_
> executable runs fine...!
> 
> If anyone has a good explanation for this, I would be dying to know. :-)
> 
> -Dimitry
> 


Nice catch!!!  

I am too waiting for the explanation....