Re: [hatari-devel] MEMWATCH freezes Hatari

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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