Re: reliable reproducer, was Re: core dump analysis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux