[hatari-devel] Debugger crash changes / zeroing global variables

Eero Tamminen oak at helsinkinet.fi
Sat Jan 14 23:13:06 CET 2012


On lauantai 14 tammikuu 2012, Nicolas Pomarède wrote:
> On 14/01/2012 22:08, Eero Tamminen wrote:
> > If the variable values were zero when entering "main", set Gdb
> > watchpoint on them.
> The value are 0 when entering main, so that's ok. But later it breaks on
> 0x080c9af4 in Video_StoreResolution (y=279) at
> /home/npomarede/src/hatari-work/src/video.c:1876
> 1876                    HBLPaletteMasks[y] |=
> and overwrites bExceptionDebugging
> Old value = 0
> New value = 393216
> y=279 in that case, which is more than NUM_VISIBLE_LINES+1 in screen.h
> I need to look at this, it seems some palette arrays are 2 lines too
> short in screen.h regarding the maximum number of possible visible lines.

Or more?  Maybe these variables aren't the first thing to be overwritten.

GCC mudflap option might be able to tell that.  To have CMake ENABLE_MUDFLAP
option available, you need to install libmudflap development package.  And
then after full recompile, run the test again.

> So, there's a very longstanding bug in Hatari with this, but it's
> possible it's only triggered in the protection code used in the
> Transbeauce Demo 2, which changes video res at very precise time.
> Initializing the variables in debugui.c move them from bss to data,
> which means they don't get overwritten now because the data block's
> order is changed by these 2 variables. But this also means some other
> variables are now being overwritten instead of those from debugui.c :(
> I will look into this and remove the unnessary init in debugui.c after
> it's fixed.

Would fix for that and WinUAE core freeze be Hatari v1.6.2?

(With possible max zoomed window size preference default reverted to what
it was in Hatari v1.4, if that's what people prefer.)

	- Eero

More information about the hatari-devel mailing list