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

[ Thread Index | Date Index | More Archives ]

Le 01/11/2018 à 22:48, Nicolas Pomarède a écrit :

Additional note : it seems the crash happens when some optimisations are enabled. cmake defaults will be -O3, but if I run "./configure --enable-debug" and modify the debug section in CMakeList.txt to use "-O0" instead of "-O", then I'm not able to crash hatari anymore. This really confirms that some memory must be leaking somewhere and its impact/crash will depend on what region get overwritten.


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.

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.

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.

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


Mail converted by MHonArc 2.6.19+