Re: pthread_getattr_np() vs explicit runtime loader

[Rich Felker <dalias@libc.org>]

On Sun, Sep 20, 2015 at 08:39:09AM +0200, u-wsnj@aetey.se wrote:
> Hello,
> 
> musl 1.1.8 on ia32 Linux, building gcc 5.2.0 succeeds.
> 
> Nevertheless a subset of the resulting executables segfault when run by
> an explicit loader (which is the vital mode of operation in our setups).
> 
> They do not seem to segfault when using the implicit loader
> which suggests the result depends on the memory mapping layout.
> 
> Moreover, the last syscalls seen before the crash are mremap(),
> presumably reflecting that pthread_getattr_np() is involved.
> 
> It looks like (according to a discussion in mail archives) the logic
> in this function makes assumptions which not necessarily are true while
> using an explicit runtime loader.
> 
> 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.

What triggered the crash to start happening? Upgrading musl? Upgrading
gcc? Have you used gdb to get a backtrace and see where the program
actually crashes?

Rich