From owner-freebsd-ports@FreeBSD.ORG Fri Jan 31 15:50:47 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 2C524634; Fri, 31 Jan 2014 15:50:47 +0000 (UTC) Received: from mail1.sysgo.com (mail1.sysgo.com [176.9.26.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8D1B1D55; Fri, 31 Jan 2014 15:50:46 +0000 (UTC) Date: Fri, 31 Jan 2014 16:50:44 +0100 From: Thomas Mueller To: Dimitry Andric Subject: Re: net/avahi-app core dumps signal 11 Message-ID: <20140131165044.0dcf979d@tmu.ulm.sysgo.com> In-Reply-To: <20140131144111.7a8544f1@tmu.ulm.sysgo.com> References: <1390354628.14798.7.camel@lenovo.toontown> <20140129115404.04922dd6@tmu.ulm.sysgo.com> <20140131144111.7a8544f1@tmu.ulm.sysgo.com> Organization: SYSGO AG X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 15:50:47 -0000 [replying to my own message, oh my] On Fri, 31 Jan 2014 14:41:11 +0100, Thomas Mueller wrote: > On Fri, 31 Jan 2014 14:15:13 +0100, Dimitry Andric wrote: > > On 29 Jan 2014, at 11:54, Thomas Mueller wrote: > > > On Tue, 21 Jan 2014 23:37:08 -0200, Sergio de Almeida Lenzi wrote: > > >> avahi-daemon dumps core, and I am unable > > >> to determinw why because it aborts core just before reaching > > >> the main() procedure.. > > >> ========================================================= > > >> > > >> #0 0x0000000801304604 in pthread_testcancel () from /lib/libthr.so.3 > > >> #1 0x00000008012fc706 in open () from /lib/libthr.so.3 > > >> #2 0x0000000801517227 in __gets_chk () from /lib/libssp.so.0 > > >> #3 0x00000008015173d2 in __chk_fail () from /lib/libssp.so.0 > > >> #4 0x0000000801516ace in .init () from /lib/libssp.so.0 > > >> #5 0x00007fffffffd130 in ?? () > > >> #6 0x000000080061e6d1 in r_debug_state () from /libexec/ld-elf.so.1 > > >> #7 0x000000080061dd57 in __tls_get_addr () from /libexec/ld-elf.so.1 > > >> #8 0x000000080061c099 in .text () from /libexec/ld-elf.so.1 > > >> #9 0x0000000000000000 in ?? () > > >> ========================================================= > > >> > > >> any ideas??? > > > > > > Seems like a bad interaction with stack protector (libssp). > > > > > > I managed to get working binaries (10.0-STABLE, amd64) by adding > > > --disable-stack-protector to CONFIGURE_ARGS > > > > Don't you think the stack protector code is trying to tell you the stack > > got smashed? :-) > > That may well be. Then there is still the quesiotn why executables > built on 9 appear to work while those built on 10 do no work. I had an older avahi build lying around on a 10-STABLE box (built December 19, 2013) and that does not show the problem. Now, when I build net/avahi-app from from current ports on that box, resulting binaries crash. [old build, December 19, 2013] nomad:/usr/ports/net/avahi-app# /usr/local/bin/avahi-browse Too few arguments [current build] nomad:/usr/ports/net/avahi-app# ./work/avahi-0.6.31/avahi-utils/.libs/avahi-browse Segmentation fault (core dumped) nomad:/usr/ports/net/avahi-app# size /usr/local/bin/avahi-browse work/avahi-0.6.31/avahi-utils/.libs/avahi-browse 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 Then there's a difference in the order of libraries in the ldd output, but I don't know if that is relevant: nomad:/usr/ports/net/avahi-app# ldd /usr/local/bin/avahi-browse work/avahi-0.6.31/avahi-utils/.libs/avahi-browse /usr/local/bin/avahi-browse: libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x800820000) libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x800a2f000) libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x800c82000) libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x800e8e000) libssp.so.0 => /lib/libssp.so.0 (0x801098000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80129a000) libthr.so.3 => /lib/libthr.so.3 (0x8014a3000) libc.so.7 => /lib/libc.so.7 (0x8016c8000) work/avahi-0.6.31/avahi-utils/.libs/avahi-browse: libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x800820000) libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x800a2f000) libthr.so.3 => /lib/libthr.so.3 (0x800c82000) libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x800ea7000) libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x8010b3000) libssp.so.0 => /lib/libssp.so.0 (0x8012bd000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x8014bf000) libc.so.7 => /lib/libc.so.7 (0x8016c8000) 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. -- Thomas Mueller