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

Eero Tamminen oak at helsinkinet.fi
Sun Jan 15 15:50:24 CET 2012


(Just when sending this, I noticed your mail.
It may still be interesting though.)

On sunnuntai 15 tammikuu 2012, Nicolas Pomarède wrote:
> On 14/01/2012 23:43, Eero Tamminen wrote:
> > On sunnuntai 15 tammikuu 2012, Nicolas Pomarède wrote:
> >> (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)
> > 
> > Could you send the demo to me (pouet.net links aren't working)?
> I sent it in a separate mail
> > Where / in which order variables are placed in memory is compiler, its
> > version and optimization level dependent.   Some compilers might put
> > also zeroed variables to BSS.  With some other compilers, their
> > versions or different compile options, more critical variables might
> > be overwritten.
> yes, of course. But in the end, I think the problem happens only with
> TB2 specific timings, so even if variables are in different order,
> unless a program does the same thing as TB2, then there should be no
> problem.

I can see what's the problem with Mudflap:
  $ sudo apt-get install libmudflap0-4.4-dev
  $ make clean; cmake -D ENABLE_MUDFLAP:BOOL=1; make
  $ MUDFLAP_OPTIONS="-viol-gdb" src/hatari --sound off trans2_a.msa

This is the first issue reported by it:
mudflap violation 1 (check/read): time=1326630156.647041 ptr=0x9ad3de0 
pc=0xb76573bd location=`/home/eero/work/hatari/src/video.c:1871:22 
      /usr/lib/libmudflap.so.0(__mf_check+0x3d) [0xb76573bd]
      src/hatari(Video_InterruptHandler_HBL+0x3f75) [0x81cbbd5]
      src/hatari(m68k_go+0x2c1) [0x831cec1]
Nearby object 1: checked region begins 0B into and ends 4B after
mudflap object 0xb212e90: name=`/home/eero/work/hatari/src/video.c:375:8 
bounds=[0x9ad3de0,0x9ad4233] size=1108 area=static check=2129r/17w 
alloc time=1326630150.155936 pc=0xb7656b2d
number of nearby objects: 1

And the invoked Gdb shows a clear logical error:
(gdb) bt
#6  0xb76573bd in __mf_check () from /usr/lib/libmudflap.so.0
#7  0x081cbbd5 in Video_StoreResolution () at 
#8  Video_EndHBL () at /home/eero/work/hatari/src/video.c:1720
#9  Video_InterruptHandler_HBL () at /home/eero/work/hatari/src/video.c:1572
#10 0x0831cec1 in m68k_run_1 (may_quit=1) at /home/eero/work/hatari/src/uae-
#11 m68k_go (may_quit=1) at /home/eero/work/hatari/src/uae-cpu/newcpu.c:1872
#12 0x081399cf in M68000_Start () at /home/eero/work/hatari/src/m68000.c:246
#13 0x0813fb46 in main (argc=4, argv=0xbfd81374) at 
static void Video_StoreResolution(int y)                                        
        Uint8 res;                                                              
        int Mask;                                                               
        /* Clear resolution, and set with current value */                      
        if (!(bUseHighRes || bUseVDIRes))                                       
                HBLPaletteMasks[y] &= ~(0x3<<16); 
... Video_EndHBL() ...
        /* Are we in possible visible color display (including borders)? */     
        else if (nHBL >= nFirstVisibleHbl && nHBL < nLastVisibleHbl)            
                /* Store resolution for every line so can check for mix...
(gdb) print nLastVisibleHbl-nFirstVisibleHbl
$1 = 400
(gdb) print nHBL-nFirstVisibleHbl
$2 = 277
(gdb) print sizeof(HBLPaletteMasks)/sizeof(HBLPaletteMasks[0])
$3 = 277
(gdb) print nScreenRefreshRate
$4 = 71
(gdb) print STRam[0xff8260] & 3
$5 = 2
(gdb) print STRam[0xff820a] & 2
$6 = 0

It would seem that HBLPaletteMasks array size / your code using the array
doesn't take into account the monochrome mode switch trick in the demo and
what effect it has on HBL numbers used to index the mask array.

Are there many other demos which use this trick?

Btw. When testing with some other things, I got also once this:
mudflap violation 1 (check/read): time=1326627178.463958 ptr=0x88e8d80 
pc=0xb76d13bd location=`/home/eero/work/hatari/src/gui-sdl/sdlgui.c:741:6 
      /usr/lib/libmudflap.so.0(__mf_check+0x3d) [0xb76d13bd]
      src/hatari(SDLGui_DoDialog+0x3db4) [0x8300e74]
      src/hatari() [0x82eb21e]
Nearby object 1: checked region begins 1B after and ends 4B after
mudflap object 0x9bd3e90: 
name=`/home/eero/work/hatari/src/falcon/nvram.c:56:14 nvram'

But I wasn't able to reproduce it / steps leading to it. :-/

	- Eero

More information about the hatari-devel mailing list