Debugger stops sending messages

[fatcerberus]

Sometimes upon performing a step, I won't receive any more notifications afterward, even though execution remains paused. What's odd is that it always happens at the same line(s), notably a seemingly benign if statement:

if (!DBG_SHOW_TITLE_SCREEN)

When executing a step at that line, my client never highlights the next line and eventually the debug connection is dropped (the target reports a TCP reset).

[svaarala]

Could you enable Duktape debug output and see what that outputs around the time of the problem? Also if you could debug log from your transport callbacks, that might help pinpoint the problem.

[fatcerberus]

Interesting. Upon performing a Step Over at the above-mentioned line, an excerpt of the output from my transport callbacks:

Receiving 1 bytes from debugger
Receiving 1 bytes from debugger
Sending 1 bytes to debugger
Sending 1 bytes to debugger
Receiving 1 bytes from debugger

A Step Over request is 3 bytes, REQ 15h (0x95) EOM. But Duktape appears to be actually performing the step after receiving REQ 15h, and starts sending stuff out before it reads the EOM. Now this technically shouldn't be an issue since TCP is a full-duplex protocol, but it intrigues me that Duktape is interleaving reading and writing like this. I would have expected it to read until EOM before doing anything else.

In any case, single-step continues to work after this, but the client doesn't highlight anything. So it may be a bug in the client and not Duktape. I will have to investigate further.

[svaarala]

That's actually intentional: message handlers will read whatever dvalues they need, and then skip to EOM ignoring the rest (which is a good default for extensibility): https://github.com/svaarala/duktape/blob/master/src/duk_debugger.c#L1620

As a side effect, once all the dvalues a command handler wants to know about have been received, the command will be executed and EOM read only when the command is done. This would be the case with all commands at present - but like you said it shouldn't matter for the client.

[fatcerberus]

Okay, after running my debugger through the debugger... :)

It turns out Duktape is sending line number 0 in all further NFYs after the offending if statement. Hence the lack of current-line highlighting.

[svaarala]

Would it be possible to reproduce the problem using the duk command line tool and web UI debugger?

[fatcerberus]

I would first have to try to come up with a test case that doesn't require the entirety of the minisphere API. And what do I need to do to use the web UI?

[fatcerberus]

Small followup that might help narrow things down: The notifications with a state of 0 (Running) appear to include the correct line number. It's only the ones with status 1 (Paused) that are being sent with line 0.

[svaarala]

Here's the basic usage: https://github.com/svaarala/duktape/blob/master/debugger/README.rst#using-the-debugger-web-ui

[fatcerberus]

Further tests reveal that Duktape is always sending a PC value of 0. Is that normal?

[fatcerberus]

Okay, I figured it out. It was a bug in the client after all, specifically an operator precedence issue regarding bitshifts. Here's how I was decoding network-order ints:

return bytes[0] << 24 + bytes[1] << 16 + bytes[2] << 8 + bytes[3];

Well, it turns out that, in C# at least, + binds tighter than << for some inexplicable reason. So the value was coming out all wrong.

Everything was alright as long as all ints were encoded in one byte, so up to line number 63 displayed fine. 64+ requires 2 or more bytes to encode, and I wasn't decoding it properly. The random disconnects were the same thing: String length decoding had the same bug, which knocked the whole stream out of sync to the point of the client being unable to recover.

[svaarala]

Same thing with C - that shift precedence thing has bitten me more times than I can count ;)