On Fri, Jan 31, 2014 at 10:57:05PM +0100, Dimitry Andric wrote: > On 31 Jan 2014, at 21:35, Dimitry Andric <[email protected]> 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.
pgplETU3QU8oV.pgp
Description: PGP signature
