Re: core dump analysis, was Re: stack smashing detected

2023-04-08 Thread Michael Schmitz
Hi Geert, Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven: Hi Michael, On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz wrote: The easiest way to do that is to log all wait and signal syscalls, as well as process exit. That might alter timing if these log messages go to the serial console tho

Re: dash behaviour, was Re: core dump analysis

2023-04-08 Thread Michael Schmitz
Hi Finn, Am 07.04.2023 um 16:03 schrieb Finn Thain: So, again, the best avenue I can think of for such experiments to modify the kernel to either keep track of the times of the wait4 syscalls and The easiest way to do that is to log all wait and signal syscalls, as well as process exit. That m

Re: core dump analysis, was Re: stack smashing detected

2023-04-08 Thread Finn Thain
On Tue, 4 Apr 2023, I wrote: > On Tue, 4 Apr 2023, I wrote: > > > > > The actual corruption might offer a clue here. I believe the saved %a3 > > was clobbered with the value 0xefee1068 which seems to be a pointer into > > some stack frame that would have come into existence shortly after > >

Re: dash behaviour, was Re: core dump analysis

2023-04-08 Thread Michael Schmitz
Hi Finn, Am 09.04.2023 um 16:42 schrieb Finn Thain: On Sun, 9 Apr 2023, Michael Schmitz wrote: The only way I have found to alter dash's inclination to crash is to reboot. (I said previously I was unable to reproduce this in a single user mode shell but it turned out to be more subtle.) I w

Re: dash behaviour, was Re: core dump analysis

2023-04-08 Thread Finn Thain
On Sun, 9 Apr 2023, Michael Schmitz wrote: > > > > The only way I have found to alter dash's inclination to crash is to > > reboot. (I said previously I was unable to reproduce this in a single > > user mode shell but it turned out to be more subtle.) > > I wonder what could change from one boo