Hi Finn, Am 14.04.2023 um 21:30 schrieb Finn Thain:
Would signal delivery erase any of the memory immediately below the USP? If so, it would erase those old stack frames, which would give some indication of the timing of signal delivery.
The signal stack is set up immediately below USP, from my reading of signal.c:setup_frame(). Old stack frames will be overwritten.
If I run dash under gdb under QEMU, I can break on entry to onsig() and find the signal frame on the stack. But when I examine stack memory from the core dump, I can't find 0x70774e40 (i.e. moveq __NR_sigreturn,%d0 ; trap #0) which the kernel puts on the stack in my QEMU experiments.
As I understand this, the call to sys_sigreturn() removes both this code (signal trampoline IIRC) and the signal stack. At that point, the kernel signal handler (which in turn calls onsig()) has already been run.
Again as far as I understand, the core dump happens on process exit. Stack smashing is detected and process exit is forced only at exit from __wait3() or __wait4_time64(), and those would have only been woken by receiving a signal. Both signal delivery and removal of signal stack by sys_sigreturn() must have happened before return from the wait syscalls.
Cheers, Michael
That suggests that no signal was delivered... and yet gotsigchld == 1 at the time of the coredump, after having been initialized by waitproc() prior to calling __wait3(). So the signal handler onsig() must have executed during __wait3() or __wait4_time64(). I can't explain this.
