Re: [hatari-devel] MEMWATCH freezes Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] MEMWATCH freezes Hatari
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Thu, 25 Oct 2018 18:18:33 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1540484314; s=strato-dkim-0002; d=seimet.de; h=In-Reply-To:References:Message-ID:Subject:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=51ieQ2QanB2oYJ/On24EXjvxoKQiVqJBm85ccP+/9iM=; b=lhoDRdQcawpiderzFtnjCNmiElQQmcMBF6/RzE62LFIAtX6rHrrH9tSlrwPdW6ivo0 KNrM3axlfPd0ISmFmOdvpUh3jj63Eylh0/vyC+BrqeTgHAso477cWPODnipab0IlFylE GQ2R+FxAP1Q4P4GhqmMMs27ALzMYK+E6vXv7AAyZ9UTZWj3p6iXQr9KFCHv38B3y46qe SWSd1dE5o7LeAls7kJAwgFmEE0/JeL+7d3pjBvV98Cv0hFl+tx1gGPXfVyotLJTE8hLL bBcMo+kdHBGX7FND2QKNDUwllgcx8d2tsNm7d48xQSd2LPZ909sSc0T4eRvF97XQTIaS TvLA==
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
>
>