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

[ Thread Index | Date Index | More Archives ]

On 19/02/2012 23:24, Eero Tamminen wrote:

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


Mail converted by MHonArc 2.6.19+