Date: Fri, 31 Jan 2014 21:35:22 +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: <E172DDDE-F695-4863-ADD5-49CB69909F1D@FreeBSD.org> In-Reply-To: <20140131165044.0dcf979d@tmu.ulm.sysgo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_B29809D2-6993-42DA-A7E9-11F77281ABD5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 31 Jan 2014, at 16:50, Thomas Mueller <tmueller@sysgo.com> wrote:
> [current build]
> nomad:/usr/ports/net/avahi-app# =
./work/avahi-0.6.31/avahi-utils/.libs/avahi-browse=20
> Segmentation fault (core dumped)
>=20
> nomad:/usr/ports/net/avahi-app# size /usr/local/bin/avahi-browse =
work/avahi-0.6.31/avahi-utils/.libs/avahi-browse=20
> text data bss dec hex filename
> 19584 1176 4488 25248 62a0 /usr/local/bin/avahi-browse
> 19584 1176 4488 25248 62a0 =
work/avahi-0.6.31/avahi-utils/.libs/avahi-browse
>=20
> Then there's a difference in the order of libraries in the ldd output,
> but I don't know if that is relevant:
>=20
> nomad:/usr/ports/net/avahi-app# ldd /usr/local/bin/avahi-browse =
work/avahi-0.6.31/avahi-utils/.libs/avahi-browse=20
> /usr/local/bin/avahi-browse:
> libavahi-client.so.3 =3D> /usr/local/lib/libavahi-client.so.3 =
(0x800820000)
> libdbus-1.so.3 =3D> /usr/local/lib/libdbus-1.so.3 (0x800a2f000)
> libavahi-common.so.3 =3D> /usr/local/lib/libavahi-common.so.3 =
(0x800c82000)
> libgdbm.so.4 =3D> /usr/local/lib/libgdbm.so.4 (0x800e8e000)
> libssp.so.0 =3D> /lib/libssp.so.0 (0x801098000)
> libintl.so.9 =3D> /usr/local/lib/libintl.so.9 (0x80129a000)
> libthr.so.3 =3D> /lib/libthr.so.3 (0x8014a3000)
> libc.so.7 =3D> /lib/libc.so.7 (0x8016c8000)
> work/avahi-0.6.31/avahi-utils/.libs/avahi-browse:
> libavahi-client.so.3 =3D> /usr/local/lib/libavahi-client.so.3 =
(0x800820000)
> libdbus-1.so.3 =3D> /usr/local/lib/libdbus-1.so.3 (0x800a2f000)
> libthr.so.3 =3D> /lib/libthr.so.3 (0x800c82000)
> libavahi-common.so.3 =3D> /usr/local/lib/libavahi-common.so.3 =
(0x800ea7000)
> libgdbm.so.4 =3D> /usr/local/lib/libgdbm.so.4 (0x8010b3000)
> libssp.so.0 =3D> /lib/libssp.so.0 (0x8012bd000)
> libintl.so.9 =3D> /usr/local/lib/libintl.so.9 (0x8014bf000)
> libc.so.7 =3D> /lib/libc.so.7 (0x8016c8000)
>=20
> On a hunch, I downgraded devel/dbus back from 1.6.18 to 1.6.12, now =
the
> resulting avahi programs no longer dump core.
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/.l=
ibs/avahi-browse
[New LWP 101263]
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);
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... :-)
-Dimitry
--Apple-Mail=_B29809D2-6993-42DA-A7E9-11F77281ABD5
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)
iEYEARECAAYFAlLsCRYACgkQsF6jCi4glqOIiACg0FJACXzwjJsO3tA5/PMCoz16
QS4AoMaQwBglyzH139UqCx74wrzJZLnC
=kKvp
-----END PGP SIGNATURE-----
--Apple-Mail=_B29809D2-6993-42DA-A7E9-11F77281ABD5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E172DDDE-F695-4863-ADD5-49CB69909F1D>