On Thu, 20 Apr 2023, Michael Schmitz wrote: > Am 20.04.2023 um 17:17 schrieb Finn Thain: > > On Thu, 20 Apr 2023, Michael Schmitz wrote: > > > >>> > >>> As with dash, the corruption lies the page boundary. > >> > >> Hence implies a page fault handled at the page boundary. > >> > >> Can you try and fault in as many of these stack pages as possible, ahead > >> of filling the stack? (Depending on how much RAM you have ...). Maybe we > >> would need to lock those pages into memory? Just to show that with no > >> page faults (but still signals) there is no corruption? > >> > > > > I modified the test program to execute rec() to full depth with no > > forking, then do it again with forking. > > > > root@(none):/root# while ./stack-test 5000 ; do : ; done > > starting recursion > > done. > > starting recursion with fork > > done. > > starting recursion > > done. > > starting recursion with fork > > Illegal instruction > > root@(none):/root# > > > > I can't get this to crash during the first descent. The second descent > > always crashes, given sufficient depth: > > > > root@(none):/root# while ./stack-test 50000 ; do : ; done > > starting recursion > > done. > > starting recursion with fork > > Illegal instruction > > > > So all the stack pages would have been faulted in well before the > > failure shows up. It appears to be the signal that's the problem and > > not the page fault. That's not surprising considering the PC in the > > signal frame in the dash crash was a MOVEM saving registers onto the > > stack. > > Well. without locking the faulted in pages in memory we can't be sure > they were not swapped back out. Unless I misunderstand what's involved > in that ... >
There was no swap enabled. 50000 frames * 36 bytes per frame == 1.8 MB
