Re: pthread_getattr_np() vs explicit runtime loader

[u-wsnj@aetey.se]

On Sun, Sep 20, 2015 at 03:41:32PM -0400, Rich Felker wrote:
> > 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

Unfortunately I could not get any useful backtrace from gdb, this
would need more time.

Hope you would make a simple crash test with
 /<path-to-musl>/libc.so /<path-to>/jv-convert.

> using boehm gc? I ask because boehm is one of the main users (iirc) of

Libjava (and then presumably jv-convert too) involves boehm gc.

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

boehm needs some patches to be buildable but this is about removing
harmful glibc-related include/define heuristics.

For the record, there are no similar crashes of jv-convert or other
binaries from an older gcc (4.2.3) built with the same musl.

Rune