Re: pthread_getattr_np() vs explicit runtime loader

[u-uy74@aetey.se]

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

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

An update:

The observed crashes were both very consequent and confusing
for the debuggers which I tried. Then I had to put this on wait.

Now when I returned to testing, the crashes do not appear any longer.

This is most probably related to the fact that the host has been rebooted
meanwhile (to the same kernel, ~ 3.18.11).

Note that I saw the crashes earlier with binaries from gcc-5.1.0 too,
i.e. this was a consistent pattern under quite some time, with different
builds, on many occasions. No similar problems with other programs
during the same time, nor any problem if using the implicit loader.

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.

Rune