Re: [hatari-devel] MEMWATCH freezes Hatari

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

Thank xou for checking this. I don't have time right now to dig deeper
into this, but from what you say Tempus Word is probably not a good
candidate for further testing our specific PMMU issues.

Best regards

Uwe

like Tempus Word should not modify
> Le 22/10/2018 à 18:48, Uwe Seimet a écrit :
> > Hi,
> > 
> > When launching the demo with MEMWATCH active it immediately returns to
> > the desktop, without anything happing. Without MEMWATCH I can start the
> > demo, and it (most likely to be expected) complains about missing fonts.
> > The version of Tempus Word I'm usually using for testing is an older
> > licensed one. That one never works, it always freezes, both with and
> > without TT-RAM. I hear several pings after starting it, which means that
> > MEMWATCH has detected violations, but then it freezes.
> > 
> 
> Hi
> 
> I had a closer look at memwatch when running tempus word ; and although 
> I still don't know why it bombs/crashes in your case, I was able to 
> reproduce the fact that the program exits nearly immediately and I'm 
> pretty sure that it would crash even on real HW.
> 
> TW is writing in its text segment here :
> 0002EB16 0c12 007f                CMP.B #$7f,(A2) [00]
> 0002EB1A 6200 00a8                BHI.W #$00a8 == $0002ebc4 (F)
> 0002EB1E 6636                     BNE.B #$36 == $0002eb56 (T)
> 0002EB56 204a                     MOVEA.L A2,A0
> 0002EB58 2248                     MOVEA.L A0,A1
> 0002EB5A 7000                     MOVE.L #$00,D0
> 0002EB5C 1018                     MOVE.B (A0)+ [00],D0
> 0002EB5E 6764                     BEQ.B #$64 == $0002ebc4 (T)
> 0002EBC4 421a                     CLR.B (A2)+
> cpu exception 2 currpc 2ebc4 buspc 2ebc4 newpc 295a2 fault_e3 0 op_e3 0 
> addr_e3 0 SR 300
> 
> The clr.b is triggering a bus error due to the page being write 
> protected. This calls memwatch's generic handler that intercept all 
> exceptions using a change of VBR ('newvec:' in the sources)
> 
> 000295A2 2f2f 0004                MOVE.L (A7, $0004) == $00005700 
> [ebc4b008],-(A7) [d3da00e0]
> 000295A6 0297 0000 0fff           AND.L #$00000fff,(A7) [ebc4b008]
> 000295AC 2eb7 0151                MOVE.L (A7, D0.W*1+0)+0 == $00000008 
> [0002d418],(A7) [00000008]
> 000295B0 4e75                     RTS
> 
> Here we see that 'newvec' at 295A2 calls the 'original' bus error 
> handler at $8 (assuming VBR=0).
> But the problem is that TW also changed several exception vectors to 
> intercept bus/address error and illegal instruction itself.
> 
> BIOS 0x05 Setexc(0x2 VEC_BUSERROR, 0x2D418) at PC 0x8482A
> BIOS 0x05 Setexc(0x3 VEC_ADDRESSERROR, 0x2D422) at PC 0x8482A
> BIOS 0x05 Setexc(0x4 VEC_ILLEGALINSTRUCTION, 0x2D42C) at PC 0x8482A
> 
> This overwrites the value that memwatch stored at address $8 to call 
> 'busserr:'
> So this calls TW's bus error handler at 2D418 instead, which intercepts 
> the bus error, creates a file 'twcore.dat' and exits.
> 
> 0002D418 33fc 0002 000c f3f6      MOVE.W #$0002,$000cf3f6 [0000]
> 0002D420 6012                     BT .B #$12 == $0002d434 (T)
> 0002D434 48f9 7fff 000c f446      MOVEM.L D0-D7/A0-A6,$000cf446
> 0002D43C 23fc 0002 ceea 000c f3fa MOVE.L #$0002ceea,$000cf3fa [00000000]
> 0002D446 204f                     MOVEA.L A7,A0
> 0002D448 43f9 000c f426           LEA.L $000cf426,A1
> [...]
> 
> 
> Instead, the correct behaviour would be that 'newvec' calls 'buserr' in 
> the case of a bus error (and not the value stored at $8).
> 
> And then 'buserr' should call the value stored at $8 (the one sets by 
> TW) only if the bus error was not caused by a write protected page.
> 
> If the bus error is due to a write protected page, buserr should change 
> ssw and do a RTE to correct the faulty write access (and not call TW's 
> bus error handler at $8).
> 
> 
> So, this still doesn't explain the crash in your case, but this explains 
> why tempus word is not compatible with memwatch, it's a bug in memwatch 
> which doesn't call its own 'busserr' handler when it should.
> A new version of memwatch would be needed with a different way to handle 
> bus error.
> 
> Nicolas
> 
> 



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/