#1427 Binary Monitor Interface - Stops at unrequested address

[Georg]

A weird problem with x64sc, using the binary monitor interface.

VICE version shows: 3.5 (GTK3 3.24.24, GLib 2.66.3)
Windows 10
x86_64 (64-bit)

Running VICE with this command:

Calling x64sc.exe with +truedrive -virtualdev -initbreak 0xa871 -binarymonitor -binarymonitoraddress 127.0.0.1:6510 -moncommands "tmpC901.tmp" "noobtrackerdisassemblytest.prg"

moncommands only has three add_labels.

The initial breakpoint is hit ($a871), should be deleted and resumed, however the monitor stops right away again at address $0811 for no reason (request in the MON_RESPONSE_STOPPED is FFFFFFFF)

Attached is the code, the assembled file and the dialog protocol.

The order in the protocol looks a bit off between sending and processing/receiving, but that shouldn't result in stopping at some seemingly random address?

[dqh]

what is the content of tmpC901.tmp?

[Georg]

In case the mailing list didn't show, it's:

add_label $0815 .getnewblock
add_label $081F .loop
add_label $082F .empty

I'm digging deeper into this, one thing that stands out, I receive four packages when the initial break point is hit, even before I send anything towards VICE:

MON_RESPONSE_CHECKPOINT_INFO - expected, shows breakpoint got hit
MON_RESPONSE_REGISTER_INFO - expected, current register info
MON_RESPONSE_STOPPED - expected, debugger stopped here
MON_RESPONSE_RESUMED <- NOT expected, why resume?

Will VICE auto-resume on the initial breakpoint?
That's something I didn't expect, so the rest may be a symptom of me sending in more messages.

[Georg]

FWIW: Someone gave me a preview version (3.4-something) to test the binary interface, and back then that MON_RESPONSE_RESUMED was not sent.

[Empathic Qubit]

I'm not sure what's happening here, but the behavior with moncommands and autostart has changed a few times before 3.5 release and I had to make some changes to my debugger to work with it. Hopefully it has stabilized now. I'll look at this though because the resume doesn't make any sense. It would make sense for the last command to be a stop.

Will VICE auto-resume on the initial breakpoint?

It shouldn't

[Empathic Qubit]

Actually, important question, are you connecting before the breakpoint gets hit? If not you may miss it, I think.

[Empathic Qubit]

I wrote a test to verify your scenario. It looks like this:

void i_love_georg(CuTest *tc) {
int length;
uint32_t response_id = 0x00000000;

uint32_t brknum;

unsigned char delete_command[] = { 
    0x02, 0x01, 
    0xff, 0xff, 0xff, 0xff, 
    0xcc, 0xd2, 0x16, 0x2b,

    0x13,

    0xff, 0xff, 0xff, 0xff,
};

unsigned char exit_command[] = {
    0x02, 0x01, 
    0xff, 0xff, 0xff, 0xff, 
    0xaf, 0xe9, 0x23, 0x3d,

    0xaa,
};


setup(tc);

while(response_id != 0xffffffff) {
    length = wait_for_response_type(tc, 0x11);
    response_id = little_endian_to_uint32(&response[RESPONSE_ID]);
}

CuAssertIntEquals(tc, 0xa871, little_endian_to_uint16(&response[HEADER_LENGTH + 5]));
CuAssertIntEquals(tc, 0xa871, little_endian_to_uint16(&response[HEADER_LENGTH + 7]));

//length = wait_for_response_type(tc, 0x62);

// delete

write_uint32(1, &delete_command[COMMAND_HEADER_LENGTH]);

send_command(delete_command);

length = wait_for_response_id(tc, delete_command);

CuAssertIntEquals(tc, 0x13, response[RESPONSE_TYPE]);

// exit

send_command(exit_command);

length = wait_for_response_id(tc, exit_command);

CuAssertIntEquals(tc, 0xaa, response[RESPONSE_TYPE]);

// resumed

length = wait_for_response_type(tc, 0x63);

CuAssertIntEquals(tc, 0x63, response[RESPONSE_TYPE]);

// stopped

length = wait_for_response_type(tc, 0x62);

CuAssertIntEquals(tc, 0x62, response[RESPONSE_TYPE]);

printf("PC: %04x\n", little_endian_to_uint16(&response[HEADER_LENGTH]));

}

This is the result:

BLAHPORT=6511 ; while ! nc -z localhost $BLAHPORT ; do echo -n . ; done ; ./remotetest $BLAHPORT i_love_georg
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................i_love_georg: request 1: CID ffffffff RID ffffffff length 34 type 11 error 0
i_love_georg: request 2: CID 2b16d2cc RID ffffffff length 54 type 31 error 0
i_love_georg: request 3: CID 2b16d2cc RID ffffffff length 14 type 62 error 0
i_love_georg: request 4: CID 2b16d2cc RID 2b16d2cc length 12 type 13 error 0
i_love_georg: request 5: CID 3d23e9af RID 3d23e9af length 12 type aa error 0
i_love_georg: request 6: CID ffffffff RID ffffffff length 14 type 63 error 0
F

There was 1 failure:
1) i_love_georg: main.c:123: assert failed

!!!FAILURES!!!
Runs: 1 Passes: 0 Fails: 1

It doesn't seem to randomly stop after the exit. It just keeps going. Does my code seem to reflect your scenario accurately? Let me know as I'm dealing with some pain and mental fog at the moment.

[Georg]

1) Yes, I am connecting before hitting the breakpoint.

2)
That seems to be the issue, yes.

It’s as if hits the breakpoint, but then simply continues on its merry way.

I had that also happen with a few other programs, at different addresses.

The fourth message (resume) is not sent from VICE in the 3.4.WIP version you sent me before the 3.5 release.
This resume is also sent if I disable all sending from my client.

[Empathic Qubit]

I can't reproduce your issue with the code I posted. The code I posted stops at the breakpoint and doesn't resume until the exit, so it seems to be working correctly. The failure is expected because it's just testing for the stop, which doesn't occur. Do you have any other ideas?

[Georg]

I'll whip up a small sample in C, using -initbreak and connecting should be enough for the resume message to appear. This is the actual problem, everything else is a followup problem (client side issue).

[Georg]

Has a few Windows-isms, but the intent should be clear. I'm starting VICE, connecting and only receive. I'd expect the last message be the STOPPED, but there's a followup RESUMED. Which I think is the issue at hand, it shouldn't resume.

Hope that helps :)

[Empathic Qubit]

What happens if you wait for VICE's connection to become active before creating the socket? I was using netcat to test for the connection before running the test program. Not sure if that would change anything.

Could you help me understand how to build your test program on Windows? I'm not well experienced with C on Windows.

[Georg]

To build you'd just create an empty C++ console project (Visual Studio), paste the file inside and hit compile. If you want here's the binary.

What do you mean with "becomes active"? Check whether the listen socket is open? How would I do that without trying to connect?

[Empathic Qubit]

I was able to compile your program with cl.exe after fiddling around a little bit. I changed it to try to connect in a loop. I tried using netcat as I did on Linux, but it was too slow to be effective. I am seeing the issue you noted now. I assume it's a Windows specific issue. I will look at this more after some sleep.

[Georg]

Awesome, if you need any further help or testing, I'm at your service!

[Empathic Qubit]

This should be fixed, but would it be possible to use the autostart command through the interface instead of passing it at the command line? You might get a better result that way.

[Empathic Qubit]

You also wouldn't have to worry about race conditions from not connecting fast enough.

[Georg]

Which autostart command are you referring to? MON_CMD_AUTOSTART ?

I'm using the command line to remote control VICE for debugging via C64Studio.
I'm using the initial breakpoint as a first step to add all other breakpoints, since I want to avoid triggering all data (store/fetch) breakpoints during the RAM initialisiation.
I'll look into MON_CMD_AUTOSTART, thanks for the hint!

[Empathic Qubit]

Can I confirm that you're still seeing this? Your test code doesn't present the issue anymore.

[Georg]

Is there a temporary Windows build of the latest changes somewhere I can use to double check?
The latest experimental binary is from december.

[gpz]

you can always get a fresh automatic build here:

https://github.com/VICE-Team/svn-mirror/releases

[Georg]

Rats, I keep forgetting. I tried with the latest available, build 40225. I see you updated the version. For testing I simply allowed version 02 as well.
With the sample code everything's fine.

Using C64Studio I still receive that breakpoint. Can it be that a MON_CMD_MEMORY_GET request enters the monitor state?

The thread 0x2ec4 has exited with code 0 (0x0).
The thread 0x3e38 has exited with code 0 (0x0).
<<<<<<< OnDataReceived 12 bytes received
<<<<<<< OnDataReceived 0202160000001100FFFFFFFF
<<<<<<< OnDataReceived 104 bytes received
<<<<<<< OnDataReceived 010000000171A871A80101040001000000000000000002022A0000003100FFFFFFFF0A00030371A803003A0003010500030214000304F80003372F0003383700030523000335C90003361F000202020000006200FFFFFFFF71A80202020000006300FFFFFFFF71A8
============ Response is MON_RESPONSE_CHECKPOINT_INFO
Processing package 0202160000001100FFFFFFFF010000000171A871A801010400010000000000000000 for request FFFFFFFF
Breakpoint 1 hit
Remove initial breakpoint 1
QueueRequest - sending data directly? Queue has 0 entries, request is DELETE_BREAKPOINT, current request type is NONE, current incoming data is 0202160000001100FFFFFFFF010000000171A871A80101040001000000000000000002022A0000003100FFFFFFFF0A00030371A803003A0003010500030214000304F80003372F0003383700030523000335C90003361F000202020000006200FFFFFFFF71A80202020000006300FFFFFFFF71A8
-no
QueueRequest - sending data directly? Queue has 1 entries, request is ADD_BREAKPOINT, current request type is NONE, current incoming data is 0202160000001100FFFFFFFF010000000171A871A80101040001000000000000000002022A0000003100FFFFFFFF0A00030371A803003A0003010500030214000304F80003372F0003383700030523000335C90003361F000202020000006200FFFFFFFF71A80202020000006300FFFFFFFF71A8
-no
QueueRequest - sending data directly? Queue has 2 entries, request is EXIT, current request type is NONE, current incoming data is 0202160000001100FFFFFFFF010000000171A871A80101040001000000000000000002022A0000003100FFFFFFFF0A00030371A803003A0003010500030214000304F80003372F0003383700030523000335C90003361F000202020000006200FFFFFFFF71A80202020000006300FFFFFFFF71A8
-no
============ Response is MON_RESPONSE_REGISTER_INFO
Processing package 02022A0000003100FFFFFFFF0A00030371A803003A0003010500030214000304F80003372F0003383700030523000335C90003361F00 for request FFFFFFFF
Register 03 = A871
Register 00 = 003A
Register 01 = 0005
Register 02 = 0014
Register 04 = 00F8
Register 37 = 002F
Register 38 = 0037
Register 05 = 0023
Register 35 = 00C9
Register 36 = 001F
============ Response is MON_RESPONSE_STOPPED
Processing package 0202020000006200FFFFFFFF71A8 for request FFFFFFFF
============ Response is MON_RESPONSE_RESUMED
Processing package 0202020000006300FFFFFFFF71A8 for request FFFFFFFF
------> StartNextRequest:DELETE_BREAKPOINT

Send Request MON_CMD_CHECKPOINT_DELETE, request ID 1
Command Body 01000000
Debugger>020104000000010000001301000000, 15 bytes
Sent 15 bytes
<<<<<<< OnDataReceived 12 bytes received
<<<<<<< OnDataReceived 02022A0000003100FFFFFFFF
<<<<<<< OnDataReceived 56 bytes received
<<<<<<< OnDataReceived 0A000303CFE5030000000301000003020A000304F20003372F00033837000305220003350000033601000202020000006200FFFFFFFFCFE5
============ Response is MON_RESPONSE_REGISTER_INFO
Processing package 02022A0000003100FFFFFFFF0A000303CFE5030000000301000003020A000304F20003372F0003383700030522000335000003360100 for request FFFFFFFF
Register 03 = E5CF
Register 00 = 0000
Register 01 = 0000
Register 02 = 000A
Register 04 = 00F2
Register 37 = 002F
Register 38 = 0037
Register 05 = 0022
Register 35 = 0000
Register 36 = 0001
QueueRequest - sending data directly? Queue has 2 entries, request is MEM_DUMP, current request type is NONE, current incoming data is 02022A0000003100FFFFFFFF0A000303CFE5030000000301000003020A000304F20003372F00033837000305220003350000033601000202020000006200FFFFFFFFCFE5
-no
============ Response is MON_RESPONSE_STOPPED
Processing package 0202020000006200FFFFFFFFCFE5 for request FFFFFFFF
------> StartNextRequest:ADD_BREAKPOINT
Send Request MON_CMD_CHECKPOINT_SET, request ID 2
Command Body 0E080E0801010400
Debugger>02010800000002000000120E080E0801010400, 19 bytes
Sent 19 bytes
<<<<<<< OnDataReceived 46 bytes received
<<<<<<< OnDataReceived 02020000000013000100000002021600000011000200000001000000000E080E0801010400000000000000000000
============ Response is MON_RESPONSE_CHECKPOINT_DELETE
Processing package 020200000000130001000000 for request 00000001
============ Response is MON_RESPONSE_CHECKPOINT_INFO
Processing package 02021600000011000200000001000000000E080E0801010400000000000000000000 for request 00000002
------> StartNextRequest:EXIT
Send Request MON_CMD_EXIT, request ID 3
Debugger>02010000000003000000AA, 11 bytes
Sent 11 bytes
<<<<<<< OnDataReceived 26 bytes received
<<<<<<< OnDataReceived 020200000000AA00030000000202020000006300FFFFFFFFCFE5
============ Response is MON_RESPONSE_EXIT
Processing package 020200000000AA0003000000 for request 00000003
============ Response is MON_RESPONSE_RESUMED
Processing package 0202020000006300FFFFFFFFCFE5 for request FFFFFFFF
------> StartNextRequest:MEM_DUMP
Send Request MON_CMD_MEMORY_GET, request ID 4
Command Body 00CFE5EEE5000000
Debugger>020108000000040000000100CFE5EEE5000000, 19 bytes
Sent 19 bytes
<<<<<<< OnDataReceived 68 bytes received
<<<<<<< OnDataReceived 02022A0000003100FFFFFFFF0A000303D1E5030000000301000003020A000304F20003372F00033837000305220003350000033602000202020000006200FFFFFFFFD1E5
============ Response is MON_RESPONSE_REGISTER_INFO
Processing package 02022A0000003100FFFFFFFF0A000303D1E5030000000301000003020A000304F20003372F0003383700030522000335000003360200 for request FFFFFFFF
Register 03 = E5D1
Register 00 = 0000
Register 01 = 0000
Register 02 = 000A
Register 04 = 00F2
Register 37 = 002F
Register 38 = 0037
Register 05 = 0022
Register 35 = 0000
Register 36 = 0002
QueueRequest - sending data directly? Queue has 0 entries, request is MEM_DUMP, current request type is NONE, current incoming data is 02022A0000003100FFFFFFFF0A000303D1E5030000000301000003020A000304F20003372F00033837000305220003350000033602000202020000006200FFFFFFFFD1E5
-no
============ Response is MON_RESPONSE_STOPPED
Processing package 0202020000006200FFFFFFFFD1E5 for request FFFFFFFF
------> StartNextRequest:MEM_DUMP
Send Request MON_CMD_MEMORY_GET, request ID 5
Command Body 00D1E5F0E5000000
Debugger>020108000000050000000100D1E5F0E5000000, 19 bytes
Sent 19 bytes
<<<<<<< OnDataReceived 92 bytes received
<<<<<<< OnDataReceived 020222000000010004000000200085CC8D9202F0F778A5CFF00CA5CEAE8702A00084CF2013EA20B4E5C983D010A202022200000001000500000020008D9202F0F778A5CFF00CA5CEAE8702A00084CF2013EA20B4E5C983D010A20978
============ Response is MON_RESPONSE_MEM_GET
Processing package 020222000000010004000000200085CC8D9202F0F778A5CFF00CA5CEAE8702A00084CF2013EA20B4E5C983D010A2 for request 00000004
MON_RESPONSE_MEM_GET from $E5CF to $E5EE
============ Response is MON_RESPONSE_MEM_GET
Processing package 02022200000001000500000020008D9202F0F778A5CFF00CA5CEAE8702A00084CF2013EA20B4E5C983D010A20978 for request 00000005
MON_RESPONSE_MEM_GET from $E5D1 to $E5F0

[Empathic Qubit]

Can you clarify what you mean by "enters the monitor state"? I thought I replied to this but I forgot that SF emails aren't replyable.

[Georg]

I mean VICE halts the emulation and enters the break state. Does it do that when a get memory request is sent? (I understand that sending a get memory request is wrong when emulation is running, just asking out of curiousity)

[Empathic Qubit]

Yes, any data sent to VICE will cause emulation to stop.