Quote:
Originally Posted by ross
Hi Toni, I keep having problems with the internal debugger.
It seems that in some cases the watchpoints (w x command, with x>0) are not respected, or certain breakpoints are not triggered.
I cannot give you precise details because everything happens in a seldom/random way.
It seems to happen often after completely changing configuration without closing and restarting WinUAE (yes, 'Restart' menu button change nothing).
Sometimes you have to shut down WinUAE because you can not get out of a HALTx situation in any way.
|
Continuing my fight with seldom debug crashes..
This time i've got something replicable.
When Amiga system got trashed i've a situation like this:
Code:
Memwatch 0: break at 0000000A.W I 00000000 PC=00000004 CPUI (000)
Cycles: 17 Chip, 34 CPU. (V=29 H=137 -> V=29 H=154)
D0 15F600FE D1 0A2600F8 D2 0A2800F8 D3 0A2A00F8
D4 0A2C00F8 D5 0A2E00F8 D6 0A3000F8 D7 0B2200F8
A0 0A3400F8 A1 0A3600F8 A2 0A3800F8 A3 0A3A00F8
A4 0A3C00F8 A5 0A3E00F8 A6 0A4000F8 A7 00000042
USP 00000042 ISP 00100000
T=00 S=0 M=0 X=0 N=1 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0a26 (EOR) 00f8 (CHK2) Chip latch 00000A26
00000004 0000 15f6 OR.B #$f6,D0
00000008 00f8 0a26 00f8 [ CHK2.B #$0a26,$00f8 ]
Next PC: 0000000a
>w
0: 00000008 - 0000005F (88) RWI CPU
>m 0
00000000 0000 0000 0000 15F6 00F8 0A26 00F8 0A28 ...........&...(
00000010 00F8 0A2A 00F8 0A2C 00F8 0A2E 00F8 0A30 ...*...,.......0
00000020 00F8 0B22 00F8 0A34 00F8 0A36 00F8 0A38 ..."...4...6...8
00000030 00F8 0A3A 00F8 0A3C 00F8 0A3E 00F8 0A40 ...:...<...>...@
00000040 00F8 0A42 00F8 0A44 00F8 0A46 00F8 0A48 ...B...D...F...H
00000050 00F8 0A4A 00F8 0A4C 00F8 0A4E 00F8 0A50 ...J...L...N...P
No other breakpoints or watchs active that the bold one.
Code I'm debugging is perfectly working without the added watch.
Logically if I continue this code system crash or halt (i've some very rare case where even WinUAE crash).
So last debug i've done I have been very attentive to the use of watchpoints.
And got this replicable crash:
- WinUAE 4.1.0 beta 8 from sticky thread or final 4.0.1 from WinUAE site (
64bit version) used;
- Quickstart A500 KS 1.3 512+513 (most common)
started with inserted floppy (I was debugging
DanDareIII-TheEscape.ipf) [but both selections are not so significative];
- start emulation and
wait CLI window appear and game begin the load;
- during the very first load time start debug and:
Code:
00FC0F94 60e6 BT .B #$e6 == $00fc0f7c (T)
Next PC: 00fc0f96
>w 0 1 3
Memwatch breakpoints enabled
0: 00000001 - 00000003 (3) RWI CPU
>w 1 0 1
1: 00000000 - 00000000 (1) RWI CPU
>W 0 80
Wrote 80 (128) at 00000000.B
>x
You got:
Code:
Memwatch 0: break at 00000002.W I 00000000 PC=00000000 CPUI (000)
Cycles: 4526 Chip, 9052 CPU. (V=105 H=0 -> V=124 H=213)
D0 00000000 D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 00000000
A0 00000000 A1 00000000 A2 00000000 A3 00000000
A4 00000000 A5 00000000 A6 00000000 A7 00000102
USP 00000102 ISP 00C80000
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0000 (OR) 8000 (OR) Chip latch 00000000
00000000 8000 OR.B D0,D0
Next PC: 00000002
>
A beautiful and inspiegabile full system crash, the same case as the former in this message.
Surely the previous one occurred during a long debugging session and I do not remember which memory cells I modified, but the casuistry is identical.
Fortunately this last combination is very simple and always repeatable so it can help Toni to understand where the problem is.
Cheers.
PS: if anyone is wondering why I used
W 0 80 is to catch a stupid bug in game module replayer that give some 'strange' volume effect at start in some configuration