Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Jan 2014 14:41:11 +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:  <20140131144111.7a8544f1@tmu.ulm.sysgo.com>
In-Reply-To: <C2CC6802-DD1B-4BD2-BA65-A694011DEAFF@FreeBSD.org>
References:  <1390354628.14798.7.camel@lenovo.toontown> <20140129115404.04922dd6@tmu.ulm.sysgo.com> <C2CC6802-DD1B-4BD2-BA65-A694011DEAFF@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> E.g. this is most likely a real buffer overflow or something, and it
> should be properly fixed, instead of removing the seat belts.

Sure.

-- 
Thomas Mueller



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140131144111.7a8544f1>