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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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