Re: reliable reproducer, was Re: core dump analysis

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