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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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.

Hi

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

Nicolas