net/avahi-app core dumps signal 11

[Konstantin Belousov]

On Fri, Jan 31, 2014 at 10:57:05PM +0100, Dimitry Andric wrote:
> 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. :-)

This sounds as if libssp initializers were run before libthr was initialized.
Indeed, open(2) must be interposed by libthr to provide the cancellation
point.

Recompile rtld with debugging symbols and debugging enabled, like this:
cd libexec/rtld-elf
make DEBUG_FLAGS=-g DEBUG=-DDEBUG
and run both binaries with the LD_DEBUG=1 env variable set, than compare.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140201/e2bfa736/attachment.sig>