[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Sep 2015 12:34:05 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: pthread_getattr_np() vs explicit runtime loader
On Sun, Sep 20, 2015 at 08:39:09AM +0200, u-wsnj@...ey.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
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.
