Re: feature tests for pthreads implementation and configuration?

In article <442933C6.F2FB1535@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Kasper Dupont <41554088040496385046@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Mikael Pettersson wrote:

The issue is that kernel 2.6.16 clears a new thread's sigaltstack
settings (as per SUSv3) while previous kernels and apparently also
Solaris 9/x86 preserved it. That caused SIGFPEs in our threads to
be delivered on the current stack (a big no-no in our runtime system)
instead of the alt stack, causing memory corruption and SIGSEGVs.

Wouldn't multiple threads using the same alternate stack for
signals be an even bigger no-no?

A no-no, yes, but not a bigger one. Our JITed code runs on stacks
that grow as needed via compiler-inserted overflow checks. That's
why signal handlers (C code not following this protocol) must be
redirected to alt stacks.

We should have made the alt stack per-thread when we started
multithreading our runtime system, but that issue was simply
forgotten due to the myriad of other changes that had to be made.
Signals in JITed code are rare enough (occasional SIGFPEs) that
things kept working (passing the test suites) even though the
alt stack wasn't thread safe.

So the 2.6.16 kernel actually did us a favour by breaking our code.
--
Mikael Pettersson (mikpe@xxxxxxxxx)
Computing Science Department, Uppsala University
.