Re: musl bug or not, real or not? (Was: [musl] Update: [musl] pthread_getattr_np() vs explicit runtime) loader

[Isaac Dunham <ibid.ag@gmail.com>]

On Tue, Oct 06, 2015 at 01:34:51PM +0200, u-uy74@aetey.se wrote:
> On Wed, Sep 30, 2015 at 10:35:48PM +0200, u-uy74@aetey.se wrote:
> > On Wed, Sep 30, 2015 at 05:43:37PM +0200, u-uy74@aetey.se wrote:
> > > 
> > > I still think that the crashes are caused by errors
> > > while guessing the stack placement in pthread_getattr_np(),
> > > simply because of the kernel doing something else than usual.
> > 
> > I can reproduce the problem and this looks like something
> > to fix or at least work around, either in gcc or in musl.
> > 
> > Running with the implicit loader works, but using the explicit one yields:
> > 
> > ----------------------------------------------------------------
> > # cat /proc/sys/kernel/randomize_va_space
> > 2
> > 
> > $ /pathtomusllibc.so --library-path /pathtogcc-5libs /pathto/jv-convert --help
> > Usage: jv-convert [OPTIONS] [INPUTFILE [OUTPUTFILE]]
> > 
> > # echo 0 > /proc/sys/kernel/randomize_va_space
> > 
> > $ /pathtomusllibc.so --library-path /pathtogcc-5libs /pathto/jv-convert --help
> > Segmentation fault
> > ----------------------------------------------------------------
> > 
> > Would anybody try this and confirm or refute?
> > 
> > Rune
> 
> Either nobody cares or nobody has a gcc-5.x toolchain built with musl?
> Wondering.

It's just that nobody cares about gcj, I think.
Now that Alpine has moved to GCC 5.2, I've tried it with the distro packages.
I've installed gcc-java;
with both randomize_va_space = 0 and 2, specifying an alternate path to the
default musl dynamic linker in the same way you did does not result in a
segfault.
Same goes with a local build of musl, using -Os.

HTH,
Isaac