Re: [hatari-devel] ide.c segfault when config changed to Falcon

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


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  
> 
> Hi
> 
> 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.

 Thomas



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