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