Date: Fri, 31 Jan 2014 22:57:05 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Thomas Mueller <tmueller@sysgo.com> Cc: ports <freebsd-ports@freebsd.org> Subject: Re: net/avahi-app core dumps signal 11 Message-ID: <A0A23193-C604-49B0-B8DD-3604055240F5@FreeBSD.org> In-Reply-To: <E172DDDE-F695-4863-ADD5-49CB69909F1D@FreeBSD.org> References: <1390354628.14798.7.camel@lenovo.toontown> <20140129115404.04922dd6@tmu.ulm.sysgo.com> <C2CC6802-DD1B-4BD2-BA65-A694011DEAFF@FreeBSD.org> <20140131144111.7a8544f1@tmu.ulm.sysgo.com> <20140131165044.0dcf979d@tmu.ulm.sysgo.com> <E172DDDE-F695-4863-ADD5-49CB69909F1D@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_E0C2A950-C571-48DF-9F62-F2FC3028C975
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 31 Jan 2014, at 21:35, Dimitry Andric <dim@FreeBSD.org> wrote:
...
> Hmm, at least I can reproduce it, but the stack trace does not tell me =
that much:
>=20
> (gdb) run
> Starting program: =
/usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/./avahi-utils/.l=
ibs/avahi-browse
> [New LWP 101263]
>=20
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 101263]
> _thr_cancel_enter (curthread=3D0x0) at =
/share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> 141 curthread->cancel_point =3D 1;
> (gdb) bt
> #0 _thr_cancel_enter (curthread=3D0x0) at =
/share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> #1 0x280d0f2d in __open (path=3D<optimized out>, flags=3D<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/gcclib=
s/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=3D<optimized out>, flags=3D<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/gcclib=
s/libssp/ssp.c:72
> 72 fd =3D open ("/dev/urandom", O_RDONLY);
>=20
> 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):=20=
cc -I.. "-DDEBUG_TRAP=3D__asm__(\"int \$3\")"
-DDATABASE_FILE=3D\"/usr/local/lib/avahi/service-types.db\" -O2 -pipe
-march=3Dcorei7 -g -fno-strict-aliasing -fstack-protector -std=3Dc99 =
-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/.li=
bs/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 =3D> /usr/local/lib/libavahi-client.so.3 =
(0x28076000)
libdbus-1.so.3 =3D> /usr/local/lib/libdbus-1.so.3 (0x28085000)
libthr.so.3 =3D> /lib/libthr.so.3 (0x280cf000)
libavahi-common.so.3 =3D> /usr/local/lib/libavahi-common.so.3 =
(0x280f1000)
libgdbm.so.4 =3D> /usr/local/lib/libgdbm.so.4 (0x280fc000)
libssp.so.0 =3D> /lib/libssp.so.0 (0x28106000)
libintl.so.9 =3D> /usr/local/lib/libintl.so.9 (0x28109000)
libc.so.7 =3D> /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 =3D> /usr/local/lib/libavahi-client.so.3 =
(0x28076000)
libdbus-1.so.3 =3D> /usr/local/lib/libdbus-1.so.3 (0x28085000)
libthr.so.3 =3D> /lib/libthr.so.3 (0x280cf000)
libavahi-common.so.3 =3D> /usr/local/lib/libavahi-common.so.3 =
(0x280f1000)
libgdbm.so.4 =3D> /usr/local/lib/libgdbm.so.4 (0x280fc000)
libintl.so.9 =3D> /usr/local/lib/libintl.so.9 (0x28106000)
libc.so.7 =3D> /lib/libc.so.7 (0x2810f000)
libssp.so.0 =3D> /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
--Apple-Mail=_E0C2A950-C571-48DF-9F62-F2FC3028C975
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlLsHDYACgkQsF6jCi4glqPB+gCg0MIkSH8rhuWyYLYTvMOES1GP
XLkAoNEInRfA+iFrS3aI2zYAcfHb0gXL
=KHKT
-----END PGP SIGNATURE-----
--Apple-Mail=_E0C2A950-C571-48DF-9F62-F2FC3028C975--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A0A23193-C604-49B0-B8DD-3604055240F5>