net/avahi-app core dumps signal 11

Dimitry Andric dim at
Fri Jan 31 21:57:27 UTC 2014

On 31 Jan 2014, at 21:35, Dimitry Andric <dim at> 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/
> #4  0x280fe749 in _init () from /lib/
> #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/ /usr/local/lib/
../avahi-common/.libs/ /usr/local/lib/ -lssp
/usr/local/lib/ -pthread -Wl,-rpath -Wl,/usr/local/lib

This executable segfaults, and has the NEEDED libs in the following

.libs/avahi-browse: => /usr/local/lib/ (0x28076000) => /usr/local/lib/ (0x28085000) => /lib/ (0x280cf000) => /usr/local/lib/ (0x280f1000) => /usr/local/lib/ (0x280fc000) => /lib/ (0x28106000) => /usr/local/lib/ (0x28109000) => /lib/ (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: => /usr/local/lib/ (0x28076000) => /usr/local/lib/ (0x28085000) => /lib/ (0x280cf000) => /usr/local/lib/ (0x280f1000) => /usr/local/lib/ (0x280fc000) => /usr/local/lib/ (0x28106000) => /lib/ (0x2810f000) => /lib/ (0x28263000)

E.g. 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. :-)


-------------- 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: <>

More information about the freebsd-ports mailing list