Re: reliable reproducer, was Re: core dump analysis

Hi Finn,

Am 21.04.2023 um 09:58 schrieb Michael Schmitz:
> 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).

2.4.30 behaves the same as recent kernels - stack corruption unless 
signal handlers use the alternate signal stack.

We already knew the 030 bus error code hasn't seen changes since 2.6, so 
this isn't much of a surprise.

I'll add some logging to the signal frame setup to print the user stack 
pointer, and perhaps do the same in the bus error handler (when hitting 
a moveml instruction).

How often did a page fault happen when executing moveml, in other programs?

Cheers,

	Michael