Frequent crashes when debugging

[davetansley]

Describe the bug While debugging with ZESaruX v0.8 (stable) I get frequent crashes, where ZESaruX will terminate and the debugging will stop. There doesn't seem to be any commonality with these crashes, they seem to happen randomly. Sometimes while stepping through instructions, sometimes while paused on a single instruction. They are not corrolated with crashes of the Spectrum code.

To Reproduce Steps to reproduce the behavior:

1. Debug code as normal

Expected behavior Stable debugging.

Version etc. (please complete the following information):

• SW Version: 0.9.1
• OS: Windows 10
• ZEsarUX SW Version: 0.8

Additional context { // Verwendet IntelliSense zum Ermitteln möglicher Attribute. // Zeigen Sie auf vorhandene Attribute, um die zugehörigen Beschreibungen anzuzeigen. // Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "type": "z80-debug", "request": "launch", "name": "ThePit", "zhostname": "localhost", "zport": 10000, "listFiles": [ { "path": "memory.list", "useFiles": true, "asm": "sjasmplus", "mainFile": "main.asm" } ], "startAutomatically": false, "skipInterrupt": true, "commandsAfterLaunch": [ //"-sprites", //"-patterns" ], "disassemblerArgs": { "esxdosRst": true }, "rootFolder": "${workspaceFolder}", "topOfStack": "stack_top", "load": "ThePit.sna", "smallValuesMaximum": 513, "tmpDir": ".tmp" }

]

}

[maziac]

It should already load both 48k sna and 128k sna (and all banks of nex files). But as you cannot switch the banks at the moment it is not so useful for 128k.

And, yes, I fixed zsim. It's good to know that I don't need to create any releases for you :-)

But, be careful, not everything I push to GitHub is working...

[kborowinski]

@maziac nex format is kind of pointless without Z80N support in z80js library ;)

[maziac]

Could you do me a favor and test once without loadDelay, i.e. removing the parameter. I would like to know If the default is working.

[kborowinski]

@maziac Well, oddly enough I do get kernel panics when loadDelay is NOT set. It is not happening on every debug but with loadDelay specified I get no kernel panics at all. Strange...

[maziac]

Ok, thanks for testing. Could you please use the latest sources (with commit 'show platform as warning'). You should get a warning when started which should look similar to this one:

Could you post its contents here.

Something different: Have you used the "state save/restore" already? Would be interesting to know if that is working for you.

[kborowinski]

@maziac You won't believe it but it seems that 500 ms delay is a sweet spot to crash Zesarux on my system:

1. [Kernel panic] default loadDelay (500 ms)

2. Custom loadDelay (250 ms)

3. [Kernel panic] - custom loadDelay (500 ms)

4. Custom loadDelay (450 ms)

I didn't try the state save/restore. Is it in command palette?

[maziac]

That is strange. Very strange. But valuable info. I will set the default to 100ms and add a comment in the documentation.

save/restore can be entered in the debug console. See here https://github.com/maziac/DeZog/blob/master/documentation/Usage.md#state-saverestore

[kborowinski]

@maziac the 100 ms is safe value on my system at least. As for save/restore it works nice on zsim but not so well on zesarux:

[maziac]

Please try once again. Should be fixed.

[kborowinski]

@maziac Yep, it works now but zsim is broken at the moment but I guess it's expected as you are implementing new features for 128K mode?

[kborowinski]

@maziac There's one more issue with Zesarux that I just found. When remote debugging at 3.5 MHz (using --denyturbotbbluerom switch) and executing code that takes couple of seconds to run the connection to Zesarux timeouts:

The Vector3D.CreateAngleRotationLUT24Bit call takes about 10 seconds to execute at 3.5 MHz and you can see that the connection timeouts. It runs OK at the default 14 MHz

[maziac]

... but zsim is broken at the moment ...

Could you please try once again. There was a problem with an entire empty zsim configuration.

But be aware that the options have changed: 'machine' is gone. To simulate a ZX 128K use "memoryPagingControl": true.

[maziac]

the connection to Zesarux timeouts

This was a very important bug you found. In fact I guess I would never have found this myself as I'm working with a timeout of 50 seconds. Otherwise I would always loose connection during debugging. The timeout defaults to 5 seconds that's why you ran into the problem and I would have never experienced it.

The problem affects step-over and step-out.

Please try once again. The fix is available in GitHub.

[kborowinski]

@maziac I've set socketTimeout to 15 seconds and problem is gone.

I've question regarding the bank layout bar in zsim:

(I honestly don't know why I didn't notice it before). It's 8K slot ZX Spectrum Next memory layout and not ordinary ZX Spectrum 128K layout. I don't know what is the best way to solve it but could you add option (or maybe a small sub-bar layout) for 16K mode (ROM, Bank 5, Bank 2, Bank 0).

And last question. I know that you are using z80js but is there a plan to add support for Z80N instruction set?

Edit: Can confirm that zsim works again

[maziac]

No, please don't set socket timeout at all. 5 secs should be more than enough. The problem with stepOver/stepOut was that they used the socketTimeout. I now use a different function, the same as for continue which doesn't expect a timeout at all. I.e. They can run forever. Imagine an endless loop in a called function, this would never return even after 15 seconds. Therefore the timeout is internally turned off for stepOver/Out.

For your other requests: I think I can do that but could you please enter 2 separate issues for those. Regarding the Z80N. I guess I will add the instructions and the memory banking but I guess that's it. No further ZXNext simulation. Just in case you are planning to use zsim for ZXNext debugging.

[maziac]

I'm about to do a 1.0.0 release and a marketplace update. Of course, I will continue development afterwards. I just wanted to ask if you see any major obstacle for a 1.0.0.

[kborowinski]

@maziac Another thing with zsim. When debugging in 128K mode ( "memoryPagingControl": true) the paging subroutines at $5b00 are missing (I guess that you don't do the 128K initialization on boot) so when IM1 handling routine at $38 calls $5b00 there is just bunch of NOPs and the debugging is stopped.

OK, I'll remove the socketTimeout and give it a try. As for the 128K bank layout I'll create another issue (maybe instead of sub-bar just small annotation at the bootom of bank layout would be enough?) . And Z80N support is enough for me, I don't need further Next simulation. When I'll get the real box the I'll remote debug with DeZog serial connection.

Edit:

I've removed the socketTimeout and debugging with Zesarux works

[maziac]

Do you have more info how the paging should work. 5B00 is in the RAM area, so I guess this will be overwritten anyway when loading the SNA file.

[kborowinski]

@maziac Well, to properly initialize $5b00 in 128K mode you would really need to emulate boot process of ZX Spectrum 128 on each debug session (or preload $5b00-$5cb6 buffer captured on real 128K box or other emulator). But what I suggest instead is to start 128K emulation in USR 0 mode, which basically is most compatible mode with most of 128K software. To do so you would need simply to set ROM1 (the 48K part of ROM) as default (instead of 128K ROM0 with editor and menu system) when initializing 128K mode and make sure that bank switching is enabled.

Edit: System variables in 128K mode

Edit2: The USR 0 mode means that you have all the 128KB memory (the bank switching is enabled) (and the 3-channel sound on real box) available, but +2/+3 BASIC is not enabled

[maziac]

USR 0 mode seems to be more appropriate. $5B00 would anyway be overwritten by the sna file or am I getting something wrong.

[kborowinski]

@maziac The SNA captured or real box or emulator in 128K mode would capture also the $5b00 buffer, so there would be no problem when loading it back BUT (there's always but) what's happening in our case is that we are running snapshot that was created/compiled by assembler (sjasmplus in this case) and thus no $5b00 area is included. Consider it as a fake snapshot.

[maziac]

OK, the default ROM is now the 48K ROM.

[kborowinski]

@maziac It works now

[kborowinski]

@maziac Zesarux debugging does not work anymore in Dezog 1.0.0 and 1.0.1. The VSC does not connect to Zesarux at all. The last working package is 0.13.7. I just cough it because I was focused on zsim testing before and didn't check if Zesarux is working in 1.0.0 and 1.0.1

[maziac]

Could you try the latest GitHub (haven't done a release yet).

[kborowinski]

It's OK now, thanks

[maziac]

@maziac Does zrcp support screen refresh? When you debug with Zesarux the emulator screen is black or does not show complete content. Is there a way to force Zesarux to periodically update emulator screen while debugging?

I just learned that there is a frame skip feature in zesarux that may prevent the screen from being updated. Disable that and hopefully the screen is updated on every step you do in the debugger: commandline "--disable-autoframeskip" or in the zesarux GUI: Settings->GUI->Autoframe Skip.

[kborowinski]

@maziac It gets better @14Mhz - thanks for the tip.

BTW are you often on discord on ZX Next channel? I'm asking because I think it's quicker to communicate than through github comments ;)

[maziac]

I have a Discord account but I'm seldom there. What's your name on Discord? I can put your name on the friends list to discuss issues directly. Personally I find Discord a little bit distractive. But I could try to be there more regularly.

[maziac]

Hi all, who have contributed to this issue.

I would like to close this issue now. There is a loadDelay time parameter in "zrcp" that allows to set a custom pause before loading the program into zesarux. This seems to "solve" the problem.

Please let me know your opinion, if I can close the issue here.

[kborowinski]

@maziac Thanks for solving that!

[maziac]

Closing this now.