Re: reliable reproducer, was Re: core dump analysis

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

 



Hi Finn,

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 ...

In my tests, increasing the depth does not cause a monotonous increase in fault probability. 16k depth only has four crashes, 8k had nine. I'll stick with 200000 for now.

Best try and narrow down how long this bug has been present - my kernel builds on the current system go back a little over ten years.

Cheers,

	Michael



It's worth noting that the test program never crashes with a corrupted
return address. Random corruption would have clobbered that address about
10% of the time, since the entire rec() stack frame is 9 long words. So it
must be that a MOVEM went awry when a signal got delivered.




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

  Powered by Linux