Re: [hatari-devel] Regression (?) in 2.4.1 - Time Slices by Defence Force

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 27/12/2022 à 11:49, Troed Sångberg a écrit :
> Hi all,
>
> Just had a discussion on mono Hatari compatibility on IRC and ran the 
> above mono demo. It's already in the compatibility list as;
>
> "Monochrome. Vertical STNICCC2015 scroll text is missing and some parts 
> of the screen have inverted colors"
>
> (this is actually one and the same issue btw)
>
> However, both on Windows 64 (official 2.4.1) and on Linux (my own build) 
> the demo now crashes/segfaults (no console output) after the "Beat 
> Slappaz" logo. This is where some synced hardware scroll should appear.
>
> 1MB STE mono tested, both EmuTOS and TOS 1.62

Hi

I confirm the crash :


Thread 1 "hatari" received signal SIGSEGV, Segmentation fault.
0x000000000062217d in Video_CopyScreenLineMono () at 
/home/npomarede/src/hatari.git/src/video.c:3425
3425            memcpy(pSTScreen, pVideoRaster, SCREENBYTES_MONOLINE);


(gdb) bt
#0  0x000000000062217d in Video_CopyScreenLineMono () at 
/home/npomarede/src/hatari.git/src/video.c:3425
#1  Video_EndHBL () at /home/npomarede/src/hatari.git/src/video.c:3180
#2  Video_InterruptHandler_HBL () at 
/home/npomarede/src/hatari.git/src/video.c:3000

it seems pVideoRaster points to out of buffer address at this point. In 
my case it happens when nHBL=87, might differ for others.


This is related to switching to "small mem" mode by default when 
compiling hatari. If I compile with

../configure --disable-small-mem

then crash goes away.

Thomas, any idea ? maybe the safe "margin" buffer that was allocated at 
the end of existing RAM is not big enough ?

Nicolas