Re: [hatari-devel] Hatari Falcon Crossbar emulation segfault with EmuTOS

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 19/02/2012 23:24, Eero Tamminen wrote:
> Hi,
>
> On sunnuntai 19 helmikuu 2012, Eero Tamminen wrote:
> > I got Hatari segfault both with new and old CPU cores when
> > trying to run EKO's system demo with latest EmuTOS snapshot.
> >
> > hatari --bios-intercept --trace xbios --fast-forward yes --tos
> > emutos-512k- CVS-20120208/etos512k.img --machine falcon
> > eko_syst.em/system.prg
> ...
> > With the old core the segfault happens a bit earlier after
> > the crossbar message.
>
> For WinUAE core, Gdb says:
> ---------------------------
> ...
> crossbar DMA Play: Illegal buffer size (from 0x0fde14 to 0x0fdde8)
> XBIOS 37 (Vsync)
> XBIOS 109 (Dsp_ExecProg)
>
> Program received signal SIGSEGV, Segmentation fault.
> Crossbar_Process_DMAPlay_Transfer ()
>      at /home/eero/work/hatari/src/falcon/crossbar.c:1452
> 1452                    value = (Sint16) pFrameStart[dmaPlay.frameCounter];
> (gdb) bt
> #0  Crossbar_Process_DMAPlay_Transfer ()
>      at /home/eero/work/hatari/src/falcon/crossbar.c:1452
> #1  0x0813e5f5 in Crossbar_InterruptHandler_25Mhz ()
>      at /home/eero/work/hatari/src/falcon/crossbar.c:1254
> (gdb) info locals
> value =<value optimized out>
> eightBits = 64
> dmaCtrlReg =<value optimized out>
> (gdb) print dmaPlay.frameCounter
> $1 = 17490220
> (gdb) print 0x0fdde8-0x0fde14
> $2 = -44
> ---------------------------
>
> Are negative DMA buffer sizes handled correctly?
>
>
> 	- Eero

I don't think they are, as this has no real meaning for dma sound.

There used to be similar cases with STE dma sound ; the problem is that 
some programs don't setup correctly dma sound address, and during a 
short period of time, you have an end address < start address. This 
usually last for 1 or 2 VBL, so not noticeable (a real STE/Falcon would 
play sound anyway, it doesn't care for end < start but will only check 
current == end to determine the sample is looping).

AFAIR I removed "<" test from the STE Dma sound, only using a "!=" test 
which is the correct way hardware works.

Nicolas



>