Re: [hatari-devel] Hatari freeze on XaAES quit with 030 MMU + FPU + cache emulation

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 29/07/2022 à 11:34, Eero Tamminen a écrit :

> Thomas' analysis of the hang on Hatari side:
>
> "When the hang happens, it seems like the emulated code is looping 
> through the whole cleared memory, only executing op_0000_35_ff() in 
> cpuemu_35.c.
>
> And this never seems to add any cycles anymore, thus Hatari completely 
> hangs in the m68k_run_mmu030() loop, without ever generating an 
> interrupt and thus not reacting to user input anymore."

Hi

this seems like a consequence of the bug to me, not its source : at one 
point, shtg goes wrong, maybe cpu jumps to a memory region containing 
only 0x00 and you get this loop.

Maybe another way to debug it :
 - can you save a memory state just before quitting XaAES
 - then start hatari with this --memstate : can you reproduce the bug 
when starting from the memstate and quitting XaAES ?

If yes, then it should be possible to run the memstate, adding "--trace 
all,-int,-cpu_regs" for example until the bug appears. This will create 
a huge log file where we can see the context much before looping the 
op_0000_35_ff().

Also if the memstate creates the bug, I think I could load the same 
memstate and have a look at the traces if you send it to me.

Nicolas