Skip to content

Tracking bug for re-establishing breakpoints in debuggers #7231

Closed

Description

@elliette

Spinning this off of dart-lang/webdev#2257, although this issue involves work for other systems besides DevTools. But I would like everything to be tracked in one place.

This all began because on web we were experiencing an issue of "phantom breakpoints" where a breakpoint that a user had removed was still being hit in Chrome, see dart-lang/webdev#2257. We would like to remove that behavior and have the debugging clients be the source of truth for breakpoints. However, while DAP clients re-establish breakpoints on hot-restart, DevTools does not.

On further investigation, we discovered that breakpoints set along the app's initial startup path in DevTools and in DAP clients don't always get hit on hot-restart or (for web) when users refresh the page. This is because breakpoints are re-set by the debugging client after the app's isolate has already started. Therefore, we want to use a combination of:

  • set_isolates_paused_on_start - make sure the app initially starts out paused
  • requirePermissionToResume(onPauseStart: true) - make sure that all connected debugging clients using set_isolates_paused_on_start send resume event before resuming
  • debugging clients send resume after they have set breakpoints

Therefore, the work required here:

Note: the following needs to be done before rolling unpinning DWDS and rolling it into google3. It was pinned here: dart-lang/sdk@4642c73

In DWDS:

In DevTools:

In DDS:

Note: This can be done after rolling DWDS into google3

In Flutter Engine:

In DAP:

  • Set requirePermissionToResume and requireUserPermissionToResume for onPauseStart and onPauseExit so that DDS waits for DAP's permission before resuming the isolate (DONE: dart-lang/sdk@93556ae)

Make sure pause_isolates_on_start is respected for hot-restarts and page refreshes for web (changes required in multiple locations):

Activity

  1. self-assigned this
    on Feb 15, 2024
  2. changed the title [-]Tracking bug for various breakpoint improvements [/-] [+]Tracking bug for re-establishing breakpoints in debuggers[/+] on Feb 15, 2024
  3. elliette commented on Feb 27, 2024

    @elliette
    MemberAuthor

    Since this requires coordination across multiple debugging clients, it makes sense to pin DWDS in g3 until everything is ready to land.

  4. added a commit that references this issue on Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions