From owner-freebsd-ports@FreeBSD.ORG Fri Jan 31 20:36:11 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DC88F23 for ; Fri, 31 Jan 2014 20:36:11 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E58B16CF for ; Fri, 31 Jan 2014 20:36:10 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b845:cd7b:51ca:897] (unknown [IPv6:2001:7b8:3a7:0:b845:cd7b:51ca:897]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9E4255C44; Fri, 31 Jan 2014 21:35:44 +0100 (CET) Subject: Re: net/avahi-app core dumps signal 11 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B29809D2-6993-42DA-A7E9-11F77281ABD5"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <20140131165044.0dcf979d@tmu.ulm.sysgo.com> Date: Fri, 31 Jan 2014 21:35:22 +0100 Message-Id: References: <1390354628.14798.7.camel@lenovo.toontown> <20140129115404.04922dd6@tmu.ulm.sysgo.com> <20140131144111.7a8544f1@tmu.ulm.sysgo.com> <20140131165044.0dcf979d@tmu.ulm.sysgo.com> To: Thomas Mueller X-Mailer: Apple Mail (2.1827) Cc: ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 20:36:11 -0000 --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 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, flags=3D) 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, flags=3D) 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--