[hatari-devel] Hatari crashes with Mental Hangover demo

[Eero Tamminen]

Hi,

On perjantai 01 huhtikuu 2011, Eero Tamminen wrote:
> On torstai 31 maaliskuu 2011, Nicolas Pomarède wrote:
>>> Is pSTscreen address taken from emulated RAM without checking that
>>> the pointed screen actually is within the emulated RAM?
>> 
>> possible, havent't checked that.
>> 
>>> Hatari crash is much more serious than demo crash. :-)
>> 
>> Yes, I agree that whatever the ST does, it should not crash Hatari, but
>> regarding this special case, it takes too much time before it crashes
>> for me and it's actually too hard to reproduce and track.

Hatari segfaults always in the same place (VBL 1654). With fast-forward that
happens within 2 secs:
-----
$ time ./hatari --fast-forward yes --frameskips 9999 --sound off --machine 
ste --tos tos162de.img mental_h.msa 
...
Segmentation fault

real    0m1.287s
-----


> So the screen value just grew infinitely.  Next question is why it
> normally doesn't grow infinitely and how to track that... :-)

Now Hatari crashes because border size gets overwritten...

#1  0x080d1185 in Video_CopyScreenLineColor () at 
/home/eero/work/hatari/src/video.c:1898
1898                    memset(pSTScreen, 0, SCREENBYTES_LINE);
(gdb) print nBorderPixelsLeft
$3 = 825505336
(gdb) print nBorderPixelsRight
$4 = 10023

(gdb) watch nBorderPixelsLeft
Hardware watchpoint 1: nBorderPixelsLeft
(gdb) watch nBorderPixelsRight
Hardware watchpoint 2: nBorderPixelsRight

(gdb) run --fast-forward yes --frameskips 9999 --sound off --machine ste --
tos tos162de.img mental_h.msa

Hardware watchpoint 1: nBorderPixelsLeft

Old value = 0
New value = 825505336
0x08094628 in FDC_DMADataFromFloppy () at 
/home/eero/work/hatari/src/fdc.c:1567
1567            memcpy(&STRam[FDC_ReadDMAAddress()], DMASectorWorkSpace, 
NUMBYTESPERSECTOR );
(gdb) bt
#0  0x08094628 in FDC_DMADataFromFloppy () at 
/home/eero/work/hatari/src/fdc.c:1567
#1  FDC_InterruptHandler_Update () at /home/eero/work/hatari/src/fdc.c:466
#2  0x0810d551 in m68k_run_1 (may_quit=1) at /home/eero/work/hatari/src/uae-
cpu/newcpu.c:1776
#3  m68k_go (may_quit=1) at /home/eero/work/hatari/src/uae-cpu/newcpu.c:1872
#4  0x080b3de4 in M68000_Start () at /home/eero/work/hatari/src/m68000.c:241
#5  0x080b4bd4 in main (argc=12, argv=0xbffff2b4) at 
/home/eero/work/hatari/src/main.c:773

(gdb) print FDC_ReadDMAAddress()
$7 = 16776850


When looking at the fdc.c, it obviously doesn't do any address validation 
before scribling over Hatari process memory with "a random" offset it got
from the emulated Atari program.

However, I'm not sure whether the right thing is to mask the FDC DMA address
to a valid address, just ignore requests with invalid address or raise an
exception?

The attached patch logs & ignores invalid FDC DMA addresses used in fdc.c
and hdc.c.  This fixes the Hatari crash, but the demo doesn't work so I
guess the address should be masked instead...?


Btw. Second patch does some code cleanup by removing from fdc.h header
anything that doesn't doesn't need to be there + sets functions only used
within fdc.c as static.  Is it OK to commit it?


	- Eero

PS. While doing the patches, I noticed:
$ grep HDCSectorCount $(find . -type f)
./hdc.h:extern short int HDCSectorCount;
./hdc.c:short int HDCSectorCount;
./hdc.c:       fprintf(hdlogFile, "HDC sector count: 0x%x\n", 
HDCSectorCount);
./fdc.c:       HDCSectorCount = 0;
./fdc.c:               DMAStatus_ff8606rd |= (HDCSectorCount)?0x2:0;         
/* HDC */
./fdc.c:               DiskControllerByte = HDCSectorCount;

What's the point in sector count that's never non-zero?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdc.diff
Type: text/x-patch
Size: 4390 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110430/fc5fb36f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanup.diff
Type: text/x-patch
Size: 11115 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110430/fc5fb36f/attachment-0001.bin>