[hatari-devel] Debugger crash changes / zeroing global variables
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
(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).
More information about the hatari-devel