DevTools automatically resumes after current breakpoint if paused when connecting

[jakemac53]

Repro instructions

Create any app, and set a breakpoint on the first line inside of main:

void main() {
  print('hello'); // Set breakpoint here
}

In VsCode, debug this app (click the debug tooltip above the main function).

It should stop at the breakpoint you set.

Click the button to open up the CPU profiler

The app will now advance past the breakpoint you set, and exit (unless you have more breakpoints set).

Expected behavior

I expect it to stay stopped at a breakpoint - I set it here in order to be able to resume it once I have connected the profiler and started recording frames.

[kenzieschmoll]

Possibly related to #8789.

[kenzieschmoll]

Possibly related to flutter/flutter#158958. @jakemac53 do you have VM Developer Mode enabled in DevTools? (Open DevTools and check the top level settings)

[jakemac53]

I do not have VM Developer Mode enabled, should I?

[kenzieschmoll]

No, you don't need to. In flutter/flutter#158958, the workaround was to disable VM Developer Mode.

I'm suspicious that this is a problem with the CPU profiler itself, but rather a problem with DevTools automatically resuming upon connecting to the app. I know @elliette worked on some breakpoint-related logic last year that could be related to this bug.

[jakemac53]

but rather a problem with DevTools automatically resuming upon connecting to the app

Yes this seems to be exactly what is happening

[jakemac53]

Indeed if I even just do the "open devtools" command pallete option - it resumes as soon as that connects.

[jakemac53]

Is this because devtools assumes it is connecting to something which hasn't actually started yet? Like an app which set pause-isolates-on-start?

[elliette]

Adding some notes here. This is something @bkonyi @DanTup and I worked on last year.

A high level summary is that DDS, which sits between our debugging tools (e.g. DevTools, IDEs) and the VM Service is responsible for deciding when to forward a resume event to the VM Service. It does so by waiting for the a readyToResume event to be sent from each of the attached debugging tools (which is the event sent by the debugging tools once they have set their breakpoints) and a normal resume event sent by the tools in response to the user triggering a resume.

What we would expect to happen here:

• User launches their app in debug mode
• DAP sets requireUserPermissionToResume. This tells DDS that it needs to wait for a resume event triggered by the user along with the readyToResume events sent from the tool

It's possible requireUserPermissionToResume wasn't correctly set, or when clicking on the CPU profiler a resume event is erroneously being sent (which would indicate to DDS that the user had clicked "resume"). Depending on what is going wrong, the fix might not be in DevTools.

[jakemac53]

I think the issue might be that this is only for the pause on start and pause on exit states? (see https://github.com/dart-lang/sdk/blob/b7a9e2b5d90807c137832c221f50d29f53d107c0/pkg/dds/lib/src/isolate_manager.dart#L446 and https://github.com/dart-lang/sdk/blob/b7a9e2b5d90807c137832c221f50d29f53d107c0/pkg/dds/lib/src/isolate_manager.dart#L99).

So, if it is paused at a user breakpoint then there isn't logic in there to not resume when it connects? Unless the _IsolateState.pauseStart state handles all pauses and not just the initial pause on startup.

[elliette]

So, if it is paused at a user breakpoint then there isn't logic in there to not resume when it connects? Unless the _IsolateState.pauseStart state handles all pauses and not just the initial pause on startup.

To clarify, by when "it connects" do you mean when DevTools connects?

I think that is possible, I think it's also possible that we are sending a resume event from DevTools when it's launched that we shouldn't be sending.

Side note: If I remember correctly, the pause start state means that isolates are initially paused on start-up and also paused after any hot-restarts.

[jakemac53]

To clarify, by when "it connects" do you mean when DevTools connects?

Yes, I think it isn't getting connected until I either open the devtools web app or open the CPU profiler, so it is connecting once the isolate is already running, but doesn't recognize/handle that?