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 21:30:33 +0200
Subject: Re: pthread_getattr_np() vs explicit runtime loader

On Sun, Sep 20, 2015 at 02:27:28PM -0400, Rich Felker wrote:
> Test program attached. It's just a very basic functionality check.


I may be misinterpreting the code but I do not see where it tests
the condition
"Furthermore, if the stack address attribute was not set in the thread
attributes object used to create the thread, then the returned thread
attributes object will report the actual stack address that the
implementation selected for the thread."

It seems to be this case which coincides with the crash.

I looked among others at

and still am unsure whether the assumptions hold while using
the explicit loader.

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

These _are_ several of the binaries of gcc-5.x which crash. It looks like
the ones which crash (java-related ones?) are using pthread_getattr_np()
while others do not. I did not though consequently check all of them.

You can easily test this if you have got say a jv-convert binary of
gcc-5.2.0, dynamically linked with musl and run this binary via the
explicit loader. Yours and mine environments are different but I would
not be surprised if the binary crashes for you too.


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.