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 12:34:05 -0400
From: Rich Felker <>
Subject: Re: pthread_getattr_np() vs explicit runtime loader

On Sun, Sep 20, 2015 at 08:39:09AM +0200, 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?


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.