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

Nicolas Pomarède npomarede at corp.free.fr
Sat Jan 14 23:27:42 CET 2012


On 14/01/2012 23:13, Eero Tamminen wrote:

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

Yes, this certainly overwritte other things, that's why I need to fix 
NUM_VISIBLE_LINES to ensure palette arrays are not access beyond their 
limit.

(no time on my side to run mudflap option, but you can give it a try if 
you want, it's quite likely you get the same crash with TB2 demo)

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

I don't know ; if there should be a 1.6.2 version, it won't be before 
one month or more on my side, I will be away for work and will have no 
time to do a new release now.

Also, I'm not sure these problems are real breakers, running hatari in 
falcon mode when using winuae cpu looks like something users can 
understand ; as for the crash in debugui, if it's only triggered when 
running TB2 demo, then initializing variables in debugui in 1.6.1 seems 
enough to run the demo (I agree it hides the problem, but if all other 
programs run well and TB2 demo runs too, then I think a 1.6.2 release is 
not needed immediatly for this problem).

Nicolas



More information about the hatari-devel mailing list