Re: reliable reproducer, was Re: core dump analysis

Hi Finn,

Am 22.04.2023 um 19:54 schrieb Michael Schmitz:
> Hi Finn,
>
> Am 21.04.2023 um 21:18 schrieb Michael Schmitz:
>> Hi Finn,
>>
>> Am 21.04.2023 um 20:30 schrieb Finn Thain:
>>> On Fri, 21 Apr 2023, Michael Schmitz wrote:
>>>
>>>>
>>>> How often did a page fault happen when executing moveml, in other
>>>> programs?
>>>>
>>>
>>> The printk() I placed in bus_error030() was conditional on the short
>>> word
>>> at the instruction pointer. It didn't consider all forms of movem, just
>>> 0x48e7 which is the start of "moveml X,%sp@-". This matched page
>>> faults in
>>> many of the programs that executed while booting to single user mode. I
>>> suppose most of them don't use signal handlers in the same way dash does
>>> otherwise they would probably be unreliable too.
>>
>> OK; so too much noise unless filtered on the command name...
>>
>> I'll try first to get register state at the time of signal delivery from
>> the sa_sigaction handler's ucontext parameter to see where the signal
>> stack falls in relation to the call frames from your rec() function on
>> the stack (and what the register contents were). Hope that won't be too
>
> Took a little while to figure out that the ucontext format changed in
> the decade or two since my userland's libc headers were generated. With
> the correct format, the information stored on th signal frame made a lot
> more sense.
>
> Log of your test program (attached), instrumented to keep track of user
> stack pointer in the parent process, user stack pointer in the signal
> handler, and stack pointer, pc and exceptiopn frame format from the
> signal stack (only the last few signals shown):
>
> parent usp  : 0xef97beb8
> handler tos : 0xef97bdc4
> handler usp : 0xef97bbe0
> signal usp  : 0xef97bea8
> signal pc   : 0xc009f37a
> signal fmtv : 0x800006ca
>
> parent usp  : 0xef969eb8
> handler tos : 0xef969dc4
> handler usp : 0xef969be0
> signal usp  : 0xef969ea8
> signal pc   : 0xc009f37a
> signal fmtv : 0x800006ca
>
> parent usp  : 0xef9530d0
> handler tos : 0xef952fec
> handler usp : 0xef952e08
> signal usp  : 0xef9530d0
> signal pc   : 0x800006dc
> signal fmtv : 0x91929394
>
> parent usp  : 0xef945eb8
> handler tos : 0xef945dc4
> handler usp : 0xef945be0
> signal usp  : 0xef945ea8
> signal pc   : 0xc009f37a
> signal fmtv : 0x800006ca
>
> parent usp  : 0xef933eb8
> handler tos : 0xef933dc4
> handler usp : 0xef933be0
> signal usp  : 0xef933ea8
> signal pc   : 0xc009f37a
> signal fmtv : 0x800006ca
>
> parent usp  : 0xef921edc
> handler tos : 0xef997984
> handler stack overwrote usp!
> handler usp : 0xef9977a0
> signal usp  : 0xef997a64
> signal pc   : 0x80000768
> signal fmtv : 0xa1a2a3a4
>
> Illegal instruction (core dumped)
>
> usp from the signal stack is below that of the parent process (before
> calling fork()).
>
> usp from the signal handler is below both of those. So far, so good.
>
> The top of the signal frame, however, is getting quite close to these
> stack pointers. In the last log, it has grown above the user stack pointer.
>
> Two things to note:
>
> - pc in the signal frame (from struct uc_mcontext) is either the return
> pc from the stack stuffing function, or something else I cannot work
> out. That part of ucontext appears valid.
>
> - what ought to be the frame format and vector offset does in fact hold
> varying longwords from the user stack. This information is not from
> struct uc_mcontext, but from extra information copied after struct
> ucontext ends. That wouldn't be there if at time of signal delivery,
> nothing had yet written to the area where the signal frame is stored.

Actually, 0x800006ca (should be format/vector but more likely a return 
address saved on the stack by rec()) is the instruction after fork() in 
rec(), and 0xc009f37a is the instuction after trap 0 in fork(). The 
signal frame pc seems to be anywhere in rec() ...

Cheers,

	Michael