[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Corruption of high TPA
On Fri, 2009-06-12 at 11:14 +0200, Vincent Rivière wrote:
> Petr Stehlik a écrit :
> > 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.
>
> Yes, we are confused ;-)
>
> You are right, the problem is the same in the FreeMiNT trap #1 handler
> as it was in the EmuTOS one. The OS reads too much data from the stack.
> Thus it crashes when the address space after the stack is not readable.
>
> But the reason why the "memory" after the stack is not readable is
> different in the 2 scenarios.
> In EmuTOS, it crashes because there is nothing valid after the stack, it
> is the end of the FastRAM.
> In FreeMiNT with memory protection, it crashes because the memory after
> the stack is made unreadable by the MMU.
>
> 2 different scenarios, but the same kind of bug in the trap handler.
>
> > 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 :)
>
> If I initialize the stack to the end of the TPA minus 64 bytes, it does
> not crash anymore. By doing this, we ensure that if some buggy os reads
> too much data from the stack, it will stay in the process TPA area, so
> it will not crash.
> By looking quickly at the FreeMiNT sources, we can see that on trap #1
> it always reads 36 bytes from the stack. EmuTOS was reading only 2 or 4
> additional bytes, I don't remember.
>
> So if in the MiNTLib startup code we keep 64 unused bytes at the top of
> the stack inside the TPA area, it will probably be enough as a
> workaround for any buggy OS.
>
> Adding a workaround in the MiNTLib is good, but fixing FreeMiNT like
> EmuTOS would be even better !
Sure. We're going to need to fix MiNTlib anwyay for buggy kernels. So
please go ahead with this Vincent.
I'll take a look at FreeMiNT on my next pass.
Alan.