[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150920194132.GO17773@brightrain.aerifal.cx>
Date: Sun, 20 Sep 2015 15:41:32 -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 09:30:33PM +0200, u-wsnj@...ey.se wrote:
> 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'm not sure what you mean. Except for the main thread, the t->stack
and t->stack_size fields store the correct values based on what was
used at pthread_create time. The distinct code paths for
caller-provided stack versus implementation-allocated stack already
took place at pthread_create time.
Moreover the case in your program is getting the stack for the main
thread, not for another thread, so the code you're asking about is not
even what's being executed.
> 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.
I don't see anywhere this code has any interacton whatsoever with how
the program was loaded. So I suspect plain old undefined behavior if
the crash depends on how it was loaded.
> > > > 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.
I might get a chance to look later, but first thought: is jv-convert
using boehm gc? I ask because boehm is one of the main users (iirc) of
pthread_getattr_np and it's full of UB. It's possible that gcc 5 broke
some of the things it's doing, or that they were already broken but
didn't happen to crash before. I think boehm needs some patches to
work safely on musl but maybe not anymore.
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.
