Update: [musl] pthread_getattr_np() vs explicit runtime loader

[u-uy74@aetey.se]

On Wed, Sep 30, 2015 at 05:43:37PM +0200, u-uy74@aetey.se wrote:
> So either this was an artifact of a "somehow specifically corrupt"
> kernel or this is some assumption which blows up, given a certain state
> (not necessarily corrupt) of the kernel. I believe more in the latter
> (is there a contract about how/where the kernel shall allocate the
> thread stacks?).
> 
> 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.
> 
> Unfortunately, in practical terms: no misbehaviour to analyze for
> the moment.

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

Convert from one encoding to another.

   --encoding FROM
   --from FROM        use FROM as source encoding name
   --to TO            use TO as target encoding name
   -i FILE            read from FILE
   -o FILE            print output to FILE
   --reverse          swap FROM and TO encodings
   --help             print this help, then exit
   --version          print version number, then exit

`-' as a file name argument can be used to refer to stdin or stdout.

# 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