|Re: [hatari-devel] Hatari segfault on cold boot with MMU + EmuTOS|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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).