Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Sep 2015 14:27:28 -0400
From: Rich Felker <>
Subject: Re: pthread_getattr_np() vs explicit runtime loader

On Sun, Sep 20, 2015 at 07:22:37PM +0200, wrote:
> On Sun, Sep 20, 2015 at 12:34:05PM -0400, Rich Felker wrote:
> > On Sun, Sep 20, 2015 at 08:39:09AM +0200, wrote:
> > > Would you comment on whether this guess is correct and hopefully make
> > > pthread_getattr_np() work even with the explicit loader?
> > 
> > I reviewed the code and there are no assumptions about how the program
> > is loaded made there. And the original test program I used to test
> > pthread_getattr_np runs fine both normally and with an explicit loader
> > command. So I think the actual problem must be elsewhere, likely in
> > whatever the application is doing right after pthread_getattr_np.
> Thanks for checking, sorry that the hypothesis seems to be wrong.
> May I run a test with that program of yours?

Test program attached. It's just a very basic functionality check.

> > What triggered the crash to start happening? Upgrading musl? Upgrading
> It is the behaviour of gcc 5. This was the case when I built 5.1.0 but
> 5.2.0 was supposed to be more compatible with musl, so I did not research
> 5.1.0. Now gcc 5.2.0 behaves identically in this respect.

And both musl and the crashing app were compiled with gcc 5? If so the
problem could be on either side.

> > gcc? Have you used gdb to get a backtrace and see where the program
> > actually crashes?
> Not yet, going to. Rebuilding gcc with '-g', this takes some time.

Unless gcc is the program crashing I don't see why you need to rebuild
gcc with -g...


View attachment "getstack.c" of type "text/plain" (600 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.