Hi Finn,
one more datapoint: using sigaltstack() to set up a separate signal
stack in main() (code lifted straight from the sigaltstack man page)
does avoid the stack corruption.
That might be useful as a workaround for dash, while we're analyzing
this bug.
I wonder whether recursively growing the stack while taking signals on
the same stack is meant to be safe. Need to look at usp inside the
signal frame (i.e. at the time the program was preempted for signal
delivery) and usp at the lowest recursion depth at the time of the
signal handler running ...
Cheers,
Michael
On 21/04/23 09:58, Michael Schmitz wrote:
Hi Finn,
On 20/04/23 20:55, Finn Thain wrote:
But in any case, it looks like we can eliminate the bus error code.
Same
fault on both 030 and 040 with very different bus error handlers is
highly unlikely.
There's no failure on '040. QEMU and Motorola '040 gave the same result.
Sorry, my fault - I interpreted your mail as saying 030 and 040 gave
the same result.
Back to the drawing board ... I've got kernel images back to 2.4.30
and 2.6.37 to try and test. I'm also trying with rt signals and
alternate signal stack (rt signals show the same behaviour).
Cheers,
Michael
