[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Sep 2015 21:30:33 +0200
From: u-wsnj@...ey.se
To: musl@...ts.openwall.com
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.
Thanks.
I may be misinterpreting the code but I do not see where it tests
the condition
(http://man7.org/linux/man-pages/man3/pthread_getattr_np.3.html)
"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
http://www.openwall.com/lists/musl/2013/03/31/5
and
http://git.musl-libc.org/cgit/musl/commit/?id=5db951ef80cae8b627f95b995811bf916c069757
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.
Rune
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.
