|Re: [hatari-devel] ide.c segfault when config changed to Falcon|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] ide.c segfault when config changed to Falcon
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sat, 16 Jan 2021 19:08:39 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1610820521; bh=NOPyZyQ5h/6LFLP/K/SK6z06yE+Dg8fPVKz59Y7HbQE=; h=Date:From:To:Subject:From; b=NA2iiHFiYx4OkyEEE6BsWIjuDTlRAVb3mD+e0eLgiJ0M+aGltvASApw+RMMiHh5N/ lLNpX+0rtxrcuWLNajVsVW8W0cd3EATtbxFOTZtp5DwZW6v+b1spFG6DgMsd5JBM2V LyfdWu3PILJw39HVAtqv2k36YCPdwmKcOsM6CvHFV1NquyzDyUUyuBaubFZjX6k51C pcucvIdAzAfFiXJ+sJYhlZY1fIYLuMtB8yE5Uqz84sHrnHqjClf9xop7dSJCiDL/DP OMCQFyhBiOHATKDrh8A1/NoE+c1Ldsk4YgjZNga4s3Y9h3ON8O27wNDWmu6ihlrtlJ EnxlRTMs9GwhA==
Am Wed, 13 Jan 2021 11:17:25 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> Le 07/12/2020 à 20:46, Thomas Huth a écrit :
> > Am Mon, 7 Dec 2020 15:28:13 +0100
> > schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> >> Le 06/12/2020 à 17:59, Eero Tamminen a écrit :
> >>> Hi,
> >>> I've pushed doc updates for all the fixes.
> >>> Unless there are objections, I was thinking of
> >>> pushing also my fix for the issue with double
> >>> usage of same image through ACSI/SCSI/IDE
> >>> (the one Uwe reported).
> >> Hi
> >> I'm not against it, but on my side I don't use ACSI/SCSI/IDE, so
> >> I'm not able to test if these changes can have any side effects.
> >> More testers would be needed for this fix to ensure all cases are
> >> handled.
> > FWIW, the patches look pretty straight-forward to me, so I think it
> > should be safe to commit them. I currently don't have much spare
> > time for testing, though, sorry.
> > Thomas
> unfortunately, I found another case where Hatari might crash because
> of IDE IO.
> start hatari in falcon mode (with --tos tos404.img) then do a memory
> save while falcon mode is booting (atari logo displayed in top left).
> exit hatari and restart hatari with --memstate and the name of the
> save file. hatari should start, complete the floppy test and then
> core dump when it comes to checking IDE state.
> (gdb) bt
> #0 0x00000000005f6980 in Ide_Mem_bget ()
> #1 0x0000000000691d34 in wait_cpu_cycle_read_ce020 ()
> #2 0x0000000000bd1070 in op_4a39_24_ff ()
> #3 0x000000000066fca8 in m68k_run_3ce ()
> #4 0x000000000066a852 in m68k_go ()
> #5 0x00000000005bc9a3 in main ()
> In my case I don't use any IDE drive, so it's likely to be some null
> pointers in IDE part as we saw before.
Sigh. That was indeed a similar problem like the once we've seen
before. I've now tried a different approach: The IDEState is now not
allocated dynamically anymore, so this should hopefully fix those null
pointers for good.