net/avahi-app core dumps signal 11

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

net/avahi-app core dumps signal 11

sergio lenzi-3
Hello,

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???



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

net/avahi-app core dumps signal 11

sergio lenzi-3

=============gdb avahi-daemon==============
#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 ?? ()
=======================================


it is a fresh system  tested both on FreeBSD  10.0-STABLE FreeBSD
10.0-STABLE #2 r260986
and than on FreeBSD10 RELEASE.

file /etc/make.conf
===========================================
FORCE_PKG_REGISTER=y

SENDMAIL_MC=/etc/mail/sendmail.mc
SENDMAIL_CFLAGS=-I/usr/local/include/sasl -I/usr/local/include -DSASL
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2
SENDMAIL_CFLAGS+=-D_FFR_SMTP_SSL

WITH_OPENSSL_BASE=yes

MAKE_JOBS_SAFE=yes
FORCE_MAKE_JOBS=yes

WITH_NEW_XORG=  yes
WITH_GALLIUM=   yes

WITH_GTK2=yes
WITH_PKGNG=yes
WX_UNICODE=YES

WARNS=2
NO_WERROR=yes
DEFAULT_VERSIONS=python=2.7 python2=2.7
===========================================
how to reproduce:

remove avahi (pkg delete -fyx avahi)
svn the ports  (cd /usr/ports;svn up)
cd /usr/ports/net/avahi-app
make install
than when you try: avahi-daemon, the program aborts core
in an previous build of ports (On another system (that ports was built
before dec, 2013, it works)
think that the problem is in the port itsself
I now will try to rollback the net/avahi-app port from a month ago, ant
try.

Can someone confirm that please??


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

sergio lenzi-3
In reply to this post by sergio lenzi-3
Em Sex, 2014-01-24 às 18:19 +0200, Yevgen Lasman escreveu:
> Have the same problem… BUT on test machine (updated from 9.2-REL) it
> works perfectly but when updated working machine (from 9.2-REL too) to
> 10.0 it started to segfault!
>
>
>
> Now I end up with test machine with working avahi and production
> server which is can't run it

Thank you...  You notice that if you compile it on the 9.2 move it with
tar to 10.0  it works!!!

But if you compile on the 10.0 it segfaults, in a way that gdb is
useless as
it aborts BEFORE reaching the main() function...

IS there a GURU that can resolve this issue??? I need it working and
compiled on the version 10 of FreeBSD...

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Robert_Burmeister
This post was updated on .
> Have the same problem... BUT on test machine (updated from 9.2-REL) it
> works perfectly but when updated working machine (from 9.2-REL too) to
> 10.0 it started to segfault!
>
> Now I end up with test machine with working avahi and production
> server which is can't run it

Thank you...  You notice that if you compile it on the 9.2 move it with
tar to 10.0  it works!!!

But if you compile on the 10.0 it segfaults, in a way that gdb is
useless as
it aborts BEFORE reaching the main() function...

IS there a GURU that can resolve this issue??? I need it working and
compiled on the version 10 of FreeBSD...
   This is a consequence of libiconv.so.3 being removed
   and its functionality being moved into the base system with Clang.
   Leaving the converters/libiconv port installed on FreeBSD 10
   will cause errors, so your supposed to "pkg_delete -f libiconv"
   before recompiling your ports.
   But,
   libgvfsdbus.so
   libgioremote-volume-monitor.so
   libavahi-glib.so.1
   etc.,
   are still trying to link to libiconv.so.3
   which breaks avahi-app.
   The relevant ports need to be updated to use iconv from base
   when compiled on FreeBSD10+.

_______________________________________________
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Brad Karp
In reply to this post by sergio lenzi-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Burmeister wrote:
> This is a consequence of libiconv.so.3 being removed and its
> functionality being moved into the base system with Clang. Leaving
> the converters/libiconv port installed on FreeBSD 10 will cause
> errors, so your supposed to "pkg_delete -f libiconv" before
> "portupgrade -fa". But, libgvfsdbus.so
> libgioremote-volume-monitor.so libavahi-glib.so.1 etc., are still
> trying to link to libiconv.so.3 which breaks avahi-app. The
> relevant ports need to be updated to use iconv from base when
> compiled on FreeBSD10+.

Thanks for the suggestion, but I believe this is not the cause of the
SIGSEGV in avahi-daemon.

I was aware of the move of libiconv into the base system, and when I
upgraded to 10.0-RELEASE, did exactly as you suggest: I removed the
libiconv package and forced an upgrade of all ports, so that they'd
link against the base system's libiconv.

I've further verified with ldd "/usr/local/lib/lib*.so*" that I have
no shared libraries left in /usr/local/lib that were built with
dependencies on the old /usr/local/lib/libiconv.so.3. (That is, this
ldd command gives no "not found" errors.)

I therefore suspect that the cause lies elsewhere. Where exactly, I
have unfortunately not yet ascertained. Other suggestions, anyone?

(FWIW, there is also discussion of this problem, which is being
experienced by others, on the forums:
http://forums.freebsd.org/viewtopic.php?f=5&t=44521 .)

- -Brad

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLmVSkACgkQNz6hPDTA3IFhXACghMZioudrZ3od4Q90Q/BvqKGJ
+7MAn07+vmywUcDN6wpa97/dN4O9H60V
=7TkE
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Robert_Burmeister
Brad Karp wrote
Thanks for the suggestion, but I believe this is not the cause of the
SIGSEGV in avahi-daemon.

I was aware of the move of libiconv into the base system, and when I
upgraded to 10.0-RELEASE, did exactly as you suggest: I removed the
libiconv package and forced an upgrade of all ports, so that they'd
link against the base system's libiconv.

I've further verified with ldd "/usr/local/lib/lib*.so*" that I have
no shared libraries left in /usr/local/lib that were built with
dependencies on the old /usr/local/lib/libiconv.so.3. (That is, this
ldd command gives no "not found" errors.)

I therefore suspect that the cause lies elsewhere. Where exactly, I
have unfortunately not yet ascertained. Other suggestions, anyone?

(FWIW, there is also discussion of this problem, which is being
experienced by others, on the forums:
http://forums.freebsd.org/viewtopic.php?f=5&t=44521 .)

- -Brad
People who deleted all ports, removed /usr/local and reinstalled
have reported that they do not have the problem.

I have deleted the contents of /usr/local/lib and am running a portupgrade -afu

I'll report back if that is a quicker fix.
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Robert_Burmeister
In reply to this post by Brad Karp
Robert Burmeister wrote:
> This is a consequence of libiconv.so.3 being removed and its
> functionality being moved into the base system with Clang. Leaving
> the converters/libiconv port installed on FreeBSD 10 will cause
> errors, so your supposed to "pkg_delete -f libiconv" before
> "portupgrade -fa". But, libgvfsdbus.so
> libgioremote-volume-monitor.so libavahi-glib.so.1 etc., are still
> trying to link to libiconv.so.3 which breaks avahi-app. The
> relevant ports need to be updated to use iconv from base when
> compiled on FreeBSD10+.

Thanks for the suggestion, but I believe this is not the cause of the
SIGSEGV in avahi-daemon.

I was aware of the move of libiconv into the base system, and when I
upgraded to 10.0-RELEASE, did exactly as you suggest: I removed the
libiconv package and forced an upgrade of all ports, so that they'd
link against the base system's libiconv.

I've further verified with ldd "/usr/local/lib/lib*.so*" that I have
no shared libraries left in /usr/local/lib that were built with
dependencies on the old /usr/local/lib/libiconv.so.3. (That is, this
ldd command gives no "not found" errors.)

I therefore suspect that the cause lies elsewhere. Where exactly, I
have unfortunately not yet ascertained. Other suggestions, anyone?
I noticed the ports giving problems have devel/gmake as a dependency.

A commit note for devel/gmake from 04 Sep 2013 states:
Introduce ICONV_CONFIGURE_ARG variable defined at Uses/iconv.mk.
It's value is "--with-libiconv-prefix=/usr/local" for systems
before 100043 with ports libiconv and to use at systems post
100043 with base iconv it's value is "" (NULL).
Will check to see if this flag is being set properly after the current recompile round.
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Robert_Burmeister
In reply to this post by Robert_Burmeister
People who deleted all ports, removed /usr/local and reinstalled
have reported that they do not have the problem.

I have deleted the contents of /usr/local/lib and am running a portupgrade -afu

I'll report back if that is a quicker fix.
Amazing, this worked.

Apparently, some Gnome components are finicky about how they are built.
A note from
https://wiki.gnome.org/Projects/Jhbuild/FreeBSD
Remove all .la files from the packages you just installed to prevent problems during the build.
You'll have to remember to do this again each time you install more packages.
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Robert_Burmeister
Amazing, this worked.
Nope, built but still fails. :-(
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Koop Mast-2
In reply to this post by Robert_Burmeister
On 29-1-2014 4:12, Robert_Burmeister wrote:

>> People who deleted all ports, removed /usr/local and reinstalled
>> have reported that they do not have the problem.
>>
>> I have deleted the contents of /usr/local/lib and am running a portupgrade
>> -afu
>>
>> I'll report back if that is a quicker fix.
> Amazing, this worked.
>
> Apparently, some Gnome components are finicky about how they are built.
> A note from
> https://wiki.gnome.org/Projects/Jhbuild/FreeBSD
>
>> Remove all .la files from the packages you just installed to prevent
>> problems during the build.
>> You'll have to remember to do this again each time you install more
>> packages.
That wiki page is only for when your trying to build gnome with Jhbuild.
I should also note that, that page is very WIP heavy.


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Thomas Mueller-10
In reply to this post by sergio lenzi-3
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

--
Thomas Mueller
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

sergio lenzi-3
Em Qua, 2014-01-29 às 11:54 +0100, Thomas Mueller escreveu:

> 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
>

Ok... thank you for the "tip"   I will check ASAP...


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Erich Dollansky-7
Hi,

On Fri, 31 Jan 2014 04:40:32 -0200
Sergio de Almeida Lenzi <[hidden email]> wrote:

> Em Qua, 2014-01-29 às 11:54 +0100, Thomas Mueller escreveu:
>
> > 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
> >
I just did this and can confirm that this helps.

Erich
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Dimitry Andric-4
In reply to this post by Thomas Mueller-10
On 29 Jan 2014, at 11:54, Thomas Mueller <[hidden email]> 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? :-)

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

-Dimitry


signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Thomas Mueller-10
On Fri, 31 Jan 2014 14:15:13 +0100, Dimitry Andric wrote:

> On 29 Jan 2014, at 11:54, Thomas Mueller <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Thomas Mueller-10
[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 <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Dimitry Andric-4
On 31 Jan 2014, at 16:50, Thomas Mueller <[hidden email]> wrote:

> [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.
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/.libs/avahi-browse
[New LWP 101263]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 101263]
_thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
141             curthread->cancel_point = 1;
(gdb) bt
#0  _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
#1  0x280d0f2d in __open (path=<optimized out>, flags=<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/gcclibs/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=<optimized out>, flags=<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/gcclibs/libssp/ssp.c:72
72        fd = 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


signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Dimitry Andric-4
On 31 Jan 2014, at 21:35, Dimitry Andric <[hidden email]> wrote:
...

> 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/.libs/avahi-browse
> [New LWP 101263]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 101263]
> _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> 141             curthread->cancel_point = 1;
> (gdb) bt
> #0  _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> #1  0x280d0f2d in __open (path=<optimized out>, flags=<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/gcclibs/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=<optimized out>, flags=<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/gcclibs/libssp/ssp.c:72
> 72        fd = 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... :-)
So avahi-browse gets linked as follows (wrapped a little for clarity):

cc -I.. "-DDEBUG_TRAP=__asm__(\"int \$3\")"
-DDATABASE_FILE=\"/usr/local/lib/avahi/service-types.db\" -O2 -pipe
-march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall
-W -Wextra -pedantic -pipe -Wformat -Wold-style-definition
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith
-Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
-fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing
-o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o
avahi_browse-stdb.o -L/usr/local/lib
../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so
-lpthread
/usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so
../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp
/usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib

This executable segfaults, and has the NEEDED libs in the following
order:

.libs/avahi-browse:
        libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
        libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
        libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
        libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
        libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
        libssp.so.0 => /lib/libssp.so.0 (0x28106000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28109000)
        libc.so.7 => /lib/libc.so.7 (0x28112000)

When I remove the -lssp from the above linking command line, it is
automatically induced anyway, but the executable then gets the following
NEEDED libs order:

.libs/avahi-browse:
        libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
        libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
        libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
        libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
        libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28106000)
        libc.so.7 => /lib/libc.so.7 (0x2810f000)
        libssp.so.0 => /lib/libssp.so.0 (0x28263000)

E.g. libssp.so.0 is now located at the end of the list.  And _this_
executable runs fine...!

If anyone has a good explanation for this, I would be dying to know. :-)

-Dimitry


signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

sergio lenzi-3
Em Sex, 2014-01-31 às 22:57 +0100, Dimitry Andric escreveu:

> On 31 Jan 2014, at 21:35, Dimitry Andric <[hidden email]> wrote:
> ...
> > 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/.libs/avahi-browse
> > [New LWP 101263]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to LWP 101263]
> > _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> > 141             curthread->cancel_point = 1;
> > (gdb) bt
> > #0  _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> > #1  0x280d0f2d in __open (path=<optimized out>, flags=<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/gcclibs/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=<optimized out>, flags=<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/gcclibs/libssp/ssp.c:72
> > 72        fd = 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... :-)
>
> So avahi-browse gets linked as follows (wrapped a little for clarity):
>
> cc -I.. "-DDEBUG_TRAP=__asm__(\"int \$3\")"
> -DDATABASE_FILE=\"/usr/local/lib/avahi/service-types.db\" -O2 -pipe
> -march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall
> -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition
> -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations
> -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
> -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith
> -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
> -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing
> -o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o
> avahi_browse-stdb.o -L/usr/local/lib
> ../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so
> -lpthread
> /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so
> ../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp
> /usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib
>
> This executable segfaults, and has the NEEDED libs in the following
> order:
>
> .libs/avahi-browse:
>         libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
>         libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
>         libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
>         libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
>         libssp.so.0 => /lib/libssp.so.0 (0x28106000)
>         libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28109000)
>         libc.so.7 => /lib/libc.so.7 (0x28112000)
>
> When I remove the -lssp from the above linking command line, it is
> automatically induced anyway, but the executable then gets the following
> NEEDED libs order:
>
> .libs/avahi-browse:
>         libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
>         libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
>         libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
>         libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
>         libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28106000)
>         libc.so.7 => /lib/libc.so.7 (0x2810f000)
>         libssp.so.0 => /lib/libssp.so.0 (0x28263000)
>
> E.g. libssp.so.0 is now located at the end of the list.  And _this_
> executable runs fine...!
>
> If anyone has a good explanation for this, I would be dying to know. :-)
>
> -Dimitry
>


Nice catch!!!  

I am too waiting for the explanation....
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: net/avahi-app core dumps signal 11

Konstantin Belousov
In reply to this post by Dimitry Andric-4
On Fri, Jan 31, 2014 at 10:57:05PM +0100, Dimitry Andric wrote:

> On 31 Jan 2014, at 21:35, Dimitry Andric <[hidden email]> wrote:
> ...
> > 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/.libs/avahi-browse
> > [New LWP 101263]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to LWP 101263]
> > _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> > 141             curthread->cancel_point = 1;
> > (gdb) bt
> > #0  _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
> > #1  0x280d0f2d in __open (path=<optimized out>, flags=<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/gcclibs/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=<optimized out>, flags=<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/gcclibs/libssp/ssp.c:72
> > 72        fd = 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... :-)
>
> So avahi-browse gets linked as follows (wrapped a little for clarity):
>
> cc -I.. "-DDEBUG_TRAP=__asm__(\"int \$3\")"
> -DDATABASE_FILE=\"/usr/local/lib/avahi/service-types.db\" -O2 -pipe
> -march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall
> -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition
> -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations
> -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
> -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith
> -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
> -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing
> -o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o
> avahi_browse-stdb.o -L/usr/local/lib
> ../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so
> -lpthread
> /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so
> ../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp
> /usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib
>
> This executable segfaults, and has the NEEDED libs in the following
> order:
>
> .libs/avahi-browse:
>         libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
>         libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
>         libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
>         libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
>         libssp.so.0 => /lib/libssp.so.0 (0x28106000)
>         libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28109000)
>         libc.so.7 => /lib/libc.so.7 (0x28112000)
>
> When I remove the -lssp from the above linking command line, it is
> automatically induced anyway, but the executable then gets the following
> NEEDED libs order:
>
> .libs/avahi-browse:
>         libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28076000)
>         libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28085000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280cf000)
>         libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280f1000)
>         libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x280fc000)
>         libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28106000)
>         libc.so.7 => /lib/libc.so.7 (0x2810f000)
>         libssp.so.0 => /lib/libssp.so.0 (0x28263000)
>
> E.g. libssp.so.0 is now located at the end of the list.  And _this_
> executable runs fine...!
>
> If anyone has a good explanation for this, I would be dying to know. :-)
This sounds as if libssp initializers were run before libthr was initialized.
Indeed, open(2) must be interposed by libthr to provide the cancellation
point.

Recompile rtld with debugging symbols and debugging enabled, like this:
cd libexec/rtld-elf
make DEBUG_FLAGS=-g DEBUG=-DDEBUG
and run both binaries with the LD_DEBUG=1 env variable set, than compare.

attachment0 (851 bytes) Download Attachment