English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 21 July 2018, 19:51   #1
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
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
ross is online now  
Old 22 July 2018, 13:22   #2
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Latest PB0 (21/07/2018) seem to work.

I'll do other tests.

Thanks.
ross is online now  
Old 22 July 2018, 14:03   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
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.
Toni Wilen is offline  
Old 22 July 2018, 16:17   #4
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Toni Wilen View Post
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 is online now  
Old 28 August 2018, 19:55   #5
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
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 20:47. Reason: typos..
ross is online now  
Old 05 September 2018, 21:30   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
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.
Toni Wilen is offline  
Old 05 September 2018, 22:29   #7
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Toni Wilen View Post
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 is online now  
Old 22 September 2018, 19:56   #8
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
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.
ross is online now  
Old 22 September 2018, 20:53   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
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.
Toni Wilen is offline  
Old 22 September 2018, 21:03   #10
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Toni Wilen View Post
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.
ross is online now  
Old 23 September 2018, 17:48   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
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
Toni Wilen is offline  
Old 23 September 2018, 19:09   #12
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Toni Wilen View Post
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 is online now  
Old 01 November 2018, 13:49   #13
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by ross View Post
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
ross is online now  
Old 01 November 2018, 20:12   #14
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 50
Posts: 1,084
Quote:
Originally Posted by ross View Post
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.
Don_Adan is offline  
Old 01 November 2018, 21:42   #15
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Don_Adan View Post
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).
ross is online now  
Old 02 November 2018, 18:24   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
Quote:
Originally Posted by ross View Post
- 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.
Toni Wilen is offline  
Old 02 November 2018, 19:09   #17
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Toni Wilen View Post
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.
ross is online now  
Old 02 November 2018, 20:16   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
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..)
Toni Wilen is offline  
Old 02 November 2018, 21:27   #19
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,357
Quote:
Originally Posted by Toni Wilen View Post
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
>

Last edited by ross; 02 November 2018 at 21:36.
ross is online now  
Old 02 November 2018, 21:33   #20
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
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.
Toni Wilen is offline  
 


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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 17:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09813 seconds with 13 queries