Re: [hatari-devel] Hatari segfault on cold boot with MMU + EmuTOS

[ Thread Index | Date Index | More Archives ]


On 11/6/18 4:20 PM, Nicolas Pomarède wrote:
Le 01/11/2018 à 22:48, Nicolas Pomarède a écrit :
after much cpu tracing, I found the cause of the crash. It was a bad use of the TRY/CATCH/ENDTRY block used to intercept some exceptions (mainly bus errors) while fetching data from cache/memory/mmu with 68030.

Great that you found it, memory corruptions are nasty to debug.

At some point, the cpu core tried to fetch instruction words from address 0, which used the MMU to access this location. But the RAM was already cleared by the cold reset, so the MMU tables were no more there, which created a bus error. And as the bus error vector itself was also cleared, this called a 2nd bus error and a crash because the 1st bus error was not correctly unstacked (the crash was due to a longjmp to this old unstacked address). This is now fixed, it correctly does a double bus error / halt error instead of crashing.

Thanks!  Verified, no crashes anymore.

As for the cold reset itself, it triggered this error because the cold reset clears the RAM immediately but the function Video_InterruptHandler_VBL() still start a new exception to handle the emulated VBL interrupt (just before resetting the cpu core). This fetched '0' from $70 (VBL handler) and then caused the bus error described above because there was also no more MMU tables in RAM. If the user chooses "reset", this last / useless VBL interrupt is not started anymore.

Why WinUAE CPU core uses variable with name "quit_program" for
indicating emulated machine reset?

So, both cases are now fixed, Hatari should reset cleanly now with MMU (it should have affected 68000 too, but for some reason (different code path with MMU) it never crashed).

	- Eero

Mail converted by MHonArc 2.6.19+