Complete
over 1 year ago

Stepping in the simulator no longer works for me (Intel Mac, Ventura 13.4.1 (c))

Since updating to 6.2.1 (although I'm starting to think thats not relevant), I can still set breakpoints that trigger. If I then hit "go", things work as expected, and it runs until the next breakpoint. Similarly "step out" will run until the current function exits (or the next breakpoint is hit).

But step and step into no longer work. The tool palette changes to show the pause button (as if the simulator is running), but it doesn't reach the next line. And if I look at the simulator, I can tell that it's not running (ie it didn't just treat the "step" as "go"). If I then hit the pause button, it will stop on the next line. But now the simulator is "broken". Whether I hit go, step or step out, it behaves just like step did (ie the palette changes to show the pause button, but the simulator makes no progress until I hit the pause button, at which point it stops on the next line).

I assumed it was a problem with 6.2.1, but downgrading through all versions down to 4.1.5 doesn't change the behavior (and I know for certain that 4.1.5, and at least some of the 4.2.x versions worked).

I've tried multiple projects, including some of the samples, and the behavior is the same. Once I step, the only thing I can do is step; and even then I have to hit pause to complete each step.

[edit:

I've tried using mdd from the command line, and I find that after stopping at a breakpoint, it (correctly) reports something like "Hit breakpoint 1, onUpdate () at HRMultifieldView.mc:79". But "step" or "next" report: "Cannot step when location is unknown."

If I then do "bt" (to show the backtrace) or "info frame" (to show the current location, locals and arguments), "step" and "next" start working.

I'm thinking this is probably related to the problem

]

[edit2:

It's the result of a change in VSCode. Stepping works in 1.78.2, but fails in 1.79.2 and later.

Presumably something changed in the debugger protocol. Its not clear whether its a bug in VSCode, or whether Garmin's debug server needs to be updated

]

markw65
  • over 1 year ago

    vscode 1.81 is now out, and the bug is definitely fixed there.

  • over 1 year ago in reply to Kyle.ConnectIQ

    We'll continue to investigate the fix on our end as well though to prevent this from occurring a third time in the future

    After looking at the last vscode fix, I'm going to change my mind again.

    This really was a vscode bug. vscode was sending the continue event (not your debug adapter), and it was (potentially) doing so too late (ie after the stop event); but prior to https://github.com/microsoft/vscode/commit/60ce77cf1a94870266c22c5c538178430d213112 they had a bug that would reliably re-order the events, making everything work.

    I'm not convinced that their most recent fix is 100% sound (they seem to be suppressing the continue if a stop has already been seen, rather than sending the continue at the correct time), but it does seem to work, and as I said, it looks like your adapter is doing the right thing.

    Thanks for looking into it!

  • over 1 year ago

    Thanks for the report. We've confirmed that debugging works again in the upcoming 1.81 VS Code release, specifically this change. I agree that there's something on our end to fix as well, but honestly the quicker fix will be to wait for the VS Code update. We're pretty sure the problem is in a 3rd party library we're using, and a pull-up of that library doesn't fix the issue. We'll continue to investigate the fix on our end as well though to prevent this from occurring a third time in the future.

  • over 1 year ago

    A bit more debugging, and I'm fairly sure this is Garmin's bug.

    When you "step", Garmin's debug adapter first fires a "stop" event, then a "continue" event (which definitely seems wrong - you'd expect the reverse).

    Prior to the VSCode commit, these ran in parallel (in the javascript async sense), but onDidStop has a few "awaits" in it. So when the first one fires, onDidContinue runs. onDidContinue doesn't have any awaits, so it runs to completion, and then onDidStop finishes. This means that after both events have settled, the debugger thinks it's stopped, which is exactly what we want (although this appears to be by pure luck).

    The whole point of the new VSCode commit was to ensure that stop and continue events are processed in the order they're received, so that after "stop", "continue", the state is always "running", and after "continue", "stop" the state is always "stopped", regardless of "await", or how long each one takes to run. So after their fix, the "stop" and "continue" are serialized, and after both events settle, vscode thinks the program is running, but in fact it's stopped. This is why hitting the pause button takes us to the next line.

  • over 1 year ago

    I've found the commit in vscode that breaks this: https://github.com/microsoft/vscode/commit/60ce77cf1a94870266c22c5c538178430d213112. That reverts cleanly on 1.80.1, and the resulting build works correctly.

    The commit actually pre-dates the 1.78 cut; but they reverted it for 1.78.2 because of new issues.

    It was also reverted on main, but then a new version of it was added to both 1.79 and 1.80 (https://github.com/microsoft/vscode/commit/aa79bd73614b415961ae03cbb7612310e34eaedd is the commit on 1.80).

    Although reverting it on 1.80 fixes the issue, this might still be a problem with Garmin's debug server. Hopefully whoever's responsible for garmin's debug server can either fix it to work with the latest vscode, or submit a suitable issue against vscode.