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 !
-- Vincent Rivière