Re: [MiNT] Corruption of high TPA

[Petr Stehlik <pstehlik@sophics.cz>]

Vincent Rivière píše v Pá 12. 06. 2009 v 10:05 +0200:
> Petr Stehlik wrote:
> > Well, if you modified the stack so the program does not crash it's not
> > fun running it anymore, is it? What are the numbers good for now?
> 
> I modified the stack in order to be able to print something from my 
> problematic setup. However, I backuped the values of the original SP and 
> high TPA values in order to display them later.
> 
> > I added printing the SP just to show people that if it doesn't crash on
> > their setup they don't run it properly (close to ramtop).
> 
> On EmuTOS, the program crashed because the top of the TPA was exactly 
> the top of the FastRam. Now we know it is a different story with the 
> FreeMiNT kernel.

I thought it was the same story - copying more bytes from the original
stack than necessary thus reading from memory the process does not own.
Luckily it was easy to fix EmuTOS.

> Thanks to my stack adjustment, we can see that on my problematic system 
> the top of the TPA is not close to the ramtop, but is elsewhere on a 8K 
> boundary. So thanks to the good memory protection provided by 
> FreeMiNT+MMU (and accurate emulation provided by ARAnyM), we can see a 
> memory violation as expected when the buggy OS tries to read the memory 
> out of its TPA.

Sorry but this sounds like the 64 bytes adjustment is still not enough
and the program keeps crashing on FreeMiNT? But if it was crashing you
couldn't read the numbers.... I am confused :)

Petr