|Re: [hatari-devel] Hatari Falcon Crossbar emulation segfault with EmuTOS|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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.
1452 value = (Sint16) pFrameStart[dmaPlay.frameCounter];
#0 Crossbar_Process_DMAPlay_Transfer ()
#1 0x0813e5f5 in Crossbar_InterruptHandler_25Mhz ()
(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?
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.