[hatari-devel] fixed a crash when restoring a snapshot using DSP

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hello

while tracing another problem, I noticed that Hatari segfaulted when I restore a memory snapshot for Falcon+DSP.

The problem is that we have this sequence :
 1) call DSP_Init() from main
 2) call DSP_MemorySnapShot_Capture

but in DSP_Init(), we had :

if (bDspEnabled || ConfigureParams.System.nDSPType != DSP_TYPE_EMU)
  return;
dsp_core_init(DSP_TriggerHostInterrupt);

The problem is that in my case, DSP defaults to none in my hatari.cfg (my default config is STF), so DSP_Init() will return without calling dsp_core_init() and dsp_host_interrupt function pointer is null -> crash in dsp_core_hostport_update_hreq.

Fix is to call DSP_Init() also after restoring the DSP part in the memory snapshot (which also requires to remove the check for bDspEnabled that was already set to true in main.c)

With this snapshot are correctly restored.

But I think code could be simplified a bit, there're some calls to DSP_Init and DSP_UnInit when nDSPType is changed, but I wonder if it's necessary.

DSP_Init only builds a few tables, and DSP_UnInit only sets a flag, so I wonder if it would not be possible to change DSP_Init by removing the test :
        if (ConfigureParams.System.nDSPType != DSP_TYPE_EMU)
                return;
And to call it only once in main.c at start ; it shouldn't matter if we call it in STF mode for example, as dsp_core_init only sets a few tables.
The DSP_UnInit() would only be called when exiting.

Laurent, what do you think ?




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/