Debugger doesn't start

ross · 21 July 2018, 18:51

Toni, when I launch every ADF from a quickconfig (it doesn't matter which) after the first SHIFT-F12 (that works) subsequent attempts to start the debugger (CLI or GUI) does not do anything (other keys work normally).
My hdd workbench environment doesn't seem affected.
Thanks!

Found the first not working version: 4010b6

ross · 22 July 2018, 12:22

Latest PB0 (21/07/2018) seem to work.

I'll do other tests.

Thanks.

Toni Wilen · 22 July 2018, 13:03

I am still not sure how it happens (I saw it once or twice but never could duplicate it..) but it was related to STOP debugging update.

ross · 22 July 2018, 15:17

Quote:

Originally Posted by Toni Wilen

I am still not sure how it happens (I saw it once or twice but never could duplicate it..) but it was related to STOP debugging update.

Yes, sure STOP related.
I'm writing a little snippet and when I use "z" or F11 to execute a _WaitTOF() the program ignore the stop at next instruction, thrown an Arabuusimiehet.WinUAE window with "Exception 27, pc=somewheretomycode" and continue.
Never seen before.

ross · 28 August 2018, 18:55

Hi Toni, I keep having problems with the internal debugger.
The hung at SHIFT-F12 is no longer here, but there are other little things that do not works like they should.
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.

Can be somehow still related to STOP update?
I find myself using 3.x versions to avoid all this...
I know I did not helped you much, I'm sorry

However a problem always manifests itself: simple f command (stop at bootblock code init) no longer works.

Toni Wilen · 05 September 2018, 20:30

Plain "f" now works (nothing to do with STOP or anything), also better than previously because it now does not anymore break if LVO (JMP xxxxxx) is executed in RAM.

ross · 05 September 2018, 21:29

Quote:

Originally Posted by Toni Wilen

Plain "f" now works (nothing to do with STOP or anything), also better than previously because it now does not anymore break if LVO (JMP xxxxxx) is executed in RAM.

It works perfectly

Thanks!

ross · 22 September 2018, 18:56

I'm not opening a new thread for this...

How can I interpret the "mustchange" for the w command?

w <num> <address> <length> <R/W/I/F/C> [<value>[.x]] (read/write/opcode/freeze/mustchange).

I expected that with a command like this I would take a breakpoint if a part of the affected memory was modified with CPU or blitter:

w 0 56e98 200 C ALL

But nothing happen. Is not the right syntax?

What mean opcode and freeze?

Thanks.

Toni Wilen · 22 September 2018, 19:53

Freeze = any write gets ignored. Original memory value never changes.
Mustchange = only breaks if written to and value is different than old value in memory.
Opcode = only instruction opcode fetches are checked. Data read and writes ignored.

ross · 22 September 2018, 20:03

Quote:

Originally Posted by Toni Wilen

Freeze = any write gets ignored. Original memory value never changes.
Mustchange = only breaks if written to and value is different than old value in memory.
Opcode = only instruction opcode fetches are checked. Data read and writes ignored.

Ok, great options.

But what's the problem with my command line?
I made a "mustchange" event (changing a memory value, with CPU or Blitter), nothing happens.

Toni Wilen · 23 September 2018, 16:48

You still need to add W parameter. Without it all accesses are ignored (default is "nothing"). It isn't very logical and it isn't really supposed to be either

ross · 23 September 2018, 18:09

Quote:

Originally Posted by Toni Wilen

You still need to add W parameter. Without it all accesses are ignored (default is "nothing"). It isn't very logical and it isn't really supposed to be either

Ok, I accept the illogicality

Thanks!

ross · 01 November 2018, 12:49

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

Don_Adan · 01 November 2018, 19:12

Quote:

Originally Posted by ross

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

If I remember right David Whittaker made music for Dan Dare III. If it has any bugs, you can check my David Whittaker player for this music. I fixed perhaps all bugs, it can be initialisation bug.

ross · 01 November 2018, 20:42

Quote:

Originally Posted by Don_Adan

If I remember right David Whittaker made music for Dan Dare III. If it has any bugs, you can check my David Whittaker player for this music. I fixed perhaps all bugs, it can be initialisation bug.

You remember right, is a non-standard David Whittaker module.
And you are right also for bug type, is an initialisation bug.

An uninitialized pointer that read a table and set a variable volume as: (positive_value*multiplicative_factor)++, else abs(negative_value) and stop.
So if you set $0=#$80 (W 0 80) you can stop strange volume behaviour (yes, ugly, but is non-system game so..).
Anyway I'll sure give a look in your code (it's EP replayer, right?). Thanks!

However, it is only a coincidence the crash of WinUAE with this game, it is simply the last one I was patching. It happened on other occasions.

Sooner or later I must also remember to ask Toni to insert some breakpoint methods that I saw in the Hatari debugger.
They seemed excellent (used for Monkey B.'s recover).

Toni Wilen · 02 November 2018, 17:24

Quote:

Originally Posted by ross

- WinUAE 4.1.0 beta 8 from sticky thread or final 4.0.1 from WinUAE site (64bit version) used;

If you use 64-bit: 32-bit version must be also tested.

ross · 02 November 2018, 18:09

Quote:

Originally Posted by Toni Wilen

If you use 64-bit: 32-bit version must be also tested.

Just tested 4.1.0b8 and 4.0.1 final (both 32 bit): same problem.

Toni Wilen · 02 November 2018, 19:16

It is KS 1.3 weirdness. Nothing to do with WinUAE.

Set break point at C0898E and check what it does. (No, I have no idea what it tries to do..)

ross · 02 November 2018, 20:27

Quote:

Originally Posted by Toni Wilen

It is KS 1.3 weirdness. Nothing to do with WinUAE.

Set break point at C0898E and check what it does. (No, I have no idea what it tries to do..)

Sorry, I fail to understand how this can be related to KS1.3.
(i've noticed some strange code in KS1.3 that do a 'copper' search from $0 but sure do not trash all like this and is totally unrelated).

At c0898e i've nothing significative.

And I've something really similar also on Quickstart A600 (KS2.05) config:

Code:

Memwatch 0: break at 00000002.W   I 00000000 PC=80000000 CPUI (000)
Cycles: 81 Chip, 162 CPU. (V=30 H=18 -> V=30 H=99)
  D0 15F600F8   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=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0000 (OR) 8000 (OR) Chip latch 00000000
80000000 8000                     OR.B D0,D0
Next PC: 80000002
>

You used the exact same steps indicated in my previous post?
Surely it's my mistake but I do not understand exactly where it could be..

EDIT: strange output to the H command after the w trap:

Code:

>H
-1 00FC0F94 60e6                     BT .B #$e6 == $00fc0f7c (T)
 0 00000000 8000                     OR.B D0,D0
>

Toni Wilen · 02 November 2018, 20:33

I only get expected memwatch hit when that weird code reads from address zero. I can't duplicate anything else.

Note that I used simply WB 1.3 disk because you said it isn't important which disk is in use, just to boot it in CLI.

21 July 2018, 18:51	#1
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Debugger doesn't start Toni, when I launch every ADF from a quickconfig (it doesn't matter which) after the first SHIFT-F12 (that works) subsequent attempts to start the debugger (CLI or GUI) does not do anything (other keys work normally). My hdd workbench environment doesn't seem affected. Thanks! Found the first not working version: 4010b6

28 August 2018, 18:55	#5
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Hi Toni, I keep having problems with the internal debugger. The hung at SHIFT-F12 is no longer here, but there are other little things that do not works like they should. 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. Can be somehow still related to STOP update? I find myself using 3.x versions to avoid all this... I know I did not helped you much, I'm sorry However a problem always manifests itself: simple f command (stop at bootblock code init) no longer works. Last edited by ross; 28 August 2018 at 19:47. Reason: typos..

22 September 2018, 18:56	#8
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	I'm not opening a new thread for this... How can I interpret the "mustchange" for the w command? w <num> <address> <length> <R/W/I/F/C> [<value>[.x]] (read/write/opcode/freeze/mustchange). I expected that with a command like this I would take a breakpoint if a part of the affected memory was modified with CPU or blitter: w 0 56e98 200 C ALL But nothing happen. Is not the right syntax? What mean opcode and freeze? Thanks.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Debugger updates (was: WinUAE Debugger HH PC history)	selco	support.WinUAE	8	14 March 2018 22:27
Debugger doesn't work	Dr. MefistO	support.WinUAE	16	26 December 2015 21:00
Trapped II - doesn't start	John Dough	support.Games	1	22 February 2014 12:54
Winuae doesn't want to start sometimes	apachacha	support.WinUAE	6	01 January 2012 15:20
Remus doesn't start	KillaByte	support.Apps	36	09 August 2011 16:19

22 July 2018, 12:22	#2
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Latest PB0 (21/07/2018) seem to work. I'll do other tests. Thanks.

22 July 2018, 13:03	#3
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	I am still not sure how it happens (I saw it once or twice but never could duplicate it..) but it was related to STOP debugging update.

05 September 2018, 20:30	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Plain "f" now works (nothing to do with STOP or anything), also better than previously because it now does not anymore break if LVO (JMP xxxxxx) is executed in RAM.

22 September 2018, 19:53	#9
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Freeze = any write gets ignored. Original memory value never changes. Mustchange = only breaks if written to and value is different than old value in memory. Opcode = only instruction opcode fetches are checked. Data read and writes ignored.

23 September 2018, 16:48	#11
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	You still need to add W parameter. Without it all accesses are ignored (default is "nothing"). It isn't very logical and it isn't really supposed to be either

02 November 2018, 19:16	#18
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	It is KS 1.3 weirdness. Nothing to do with WinUAE. Set break point at C0898E and check what it does. (No, I have no idea what it tries to do..)

02 November 2018, 20:33	#20
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	I only get expected memwatch hit when that weird code reads from address zero. I can't duplicate anything else. Note that I used simply WB 1.3 disk because you said it isn't important which disk is in use, just to boot it in CLI.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)