Debugger needs a way to show stacktraces for all waiting async calls

[lukehutch]

Sometimes my Flutter app gets stuck on the Android splash screen, and never starts up the Flutter router. I suspect this may be due to one of several async Dart calls, in the initialization of main, preventing the Flutter app from starting, (in other words, I suspect that one of them is awaited indefinitely). However, I have no way to determine exactly where the code is stuck, because when I click Pause (in VS Code), The debugger call stack sub-window says "Paused on pause", and then shows no stacktrace.

When I click Pause, I would expect to be able to see a list of all current async calls that are awaiting completion (similar to a list of running Threads, in a Java debugger), and I should be able to view the stacktraces of all of them, to determine which async call is holding up execution by not completing.

[devoncarew]

I suspect this would need additional information in the vm service protocol to expose additional async machinery.

cc @bkonyi @DanTup

[lukehutch]

Just for context, to maximize concurrency, I frequently use await Future.wait(futuresList) with a list of numerous futures whose executions are not interdependent. Currently it's impossible to pause the debugger and see which of those futures have completed and which are still pending.

[lukehutch]

PS what does "Paused on pause" actually indicate?

[DanTup]

@lukehutch do you have a code sample/steps that gets into this state? Is it a deadlock? I'm surprised there's nothing at all in the call stack - although I suspect if it did show something, it wouldn't be helpful to you.. If I understand correctly, what you really want is a list of all places that are suspended at an await (which seem a bit like threads, but are not threads since there may be many of them that are sharing a single thread).

@bkonyi does the VM Service expose anything like this?

I don't think we have anywhere to provide that information in DAP but it doesn't seem like this information would be useful only for Dart (JS/NodeJS are very similar), so it could be worth opening a discussion in the DAP repo about it (maybe just having a hierarchy for threads would work?).

PS what does "Paused on pause" actually indicate?

When things pause, we send a DAP StoppedEvent to VS Code with a reason:

reason: 'step' | 'breakpoint' | 'exception' | 'pause' | 'entry' | 'goto'
        | 'function breakpoint' | 'data breakpoint' | 'instruction breakpoint'
        | string;

VS Code seems to just prefix the reason with "Pause on", which looks reasonable for "Paused one exception" and "Paused on breakpoint" but looks a little odd when the reason is pause.

---

Edit: There is an issue about nested threads at microsoft/debug-adapter-protocol#339

[lukehutch]

@lukehutch do you have a code sample/steps that gets into this state? Is it a deadlock? I'm surprised there's nothing at all in the call stack - although I suspect if it did show something, it wouldn't be helpful to you.. If I understand correctly, what you really want is a list of all places that are suspended at an await (which seem a bit like threads, but are not threads since there may be many of them that are sharing a single thread).

I haven't been able to get to the bottom of this yet, because of lack of debugger assistance, and the fact that the issue is sporadic.

What I see is that at least the Android part of my app will start up, because the Android splash screen is shown, but then my app never routes to the first page.

I am only assuming this is because of async code not completing, because I can't believe the Flutter Android app entry point would randomly fail to start Flutter. I have a bunch of async tasks that are run in parallel on app startup before routing takes place, and that is what I am attributing the cause to. I will post an update if I figure out what is happening.

However, separately from this specific issue that I am running into -- (and what this bug is really about) -- is the request that the debugger should be able to see all active async tasks, and their stacktraces. This is really critical to understanding a running program. I used the Java thread viewer in Eclipse many times to understand concurrent systems. In Java, you can pause individual threads separately, but in Dart/JS, you would pause the whole isolate.

[DanTup]

Thanks - I guess this would be something like the Tasks window in Visual Studio.

There are some related issues here:

• Support nesting of threads microsoft/debug-adapter-protocol#339
• Investigate debug UI for highly concurrent languages microsoft/vscode#116109

I'm not sure we could make a great experience in VS Code without some DAP/VS Code support. I'd encourage adding 👍 's to those issues.