Date: Fri, 31 Jan 2014 16:50:44 +0100 From: Thomas Mueller <tmueller@sysgo.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: ports <freebsd-ports@freebsd.org> 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> <C2CC6802-DD1B-4BD2-BA65-A694011DEAFF@FreeBSD.org> <20140131144111.7a8544f1@tmu.ulm.sysgo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 <tmueller@sysgo.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140131165044.0dcf979d>