Debugger ignores a breakpoint

[osaxma]

the issue was originally filed at Dart-Code/Dart-Code#4707

Describe the bug

The breakpoint at line 382 is ignored as shown in the screen recording below (it's taking several seconds because the setup prepares a database):

Screen.Recording.2023-08-25.at.8.49.56.PM.mov

To Reproduce
I could not reproduce outside of the project that I was working on, but I made a branch in my fork to reproduce:

1. Checkout the debugger_breakpoint_issue branch
   • link: https://github.com/osaxma/postgresql-dart/tree/debugger_breakpoint_issue
2. Make sure Docker is available -- the tests will pull the latest postgres image so first run may be slow.
3. Go to tests/v3_test.dart to line 382 and set a breakpoint as shown in the video
4. Click debug above the test and the debugger skips the breakpoint

[Update] this is a minimal code sample to reproduce

void main() {
  final int y = 0;
  /* breakpoint here would hit */ final yd = y.toDouble();

  late final int x = 1; // late initialization causes the issue
  /* breakpoint here would miss */ final xd = x.toDouble();
}

Expected behavior
I expect the debugger to hit the breakpoint.

Please complete the following information:

• Operating System and version: 12.6 (21G115)
• VS Code version: 1.81.1
• Dart extension version: v3.70.0
• Dart/Flutter SDK version: Dart SDK version: 3.1.0 (stable) (Tue Aug 15 21:33:36 2023 +0000) on "macos_x64"

---

Additional context from see @DanTup:

Nothing looks wrong in the log until the debugger pauses at the wrong place. A new isolate starts paused, we send breakpoints, the VM responds. We then resume the isolate and both breakpoints resolve, but then we hit the second breakpoint.

from: Dart-Code/Dart-Code#4707 (comment)

[osaxma]

It turns out the issue was happening because of the late initialization in the setup function.

Here's the absolute minimal code sample to reproduce:

void main() {
  final int y = 0;
  /* breakpoint here would hit */ final yd = y.toDouble();

  late final int x = 1; // late initialization causes the issue
  /* breakpoint here would miss */ final xd = x.toDouble();
}

[virmundi]

I have the same issue. While this might not be reproducible, hopefully it helps a bit.

import 'package:flutter_test/flutter_test.dart';
import 'package:my_home/db/all.dart';
import 'package:my_home/domain/all.dart';
import 'package:sqflite_common_ffi/sqflite_ffi.dart';

void main() {
  Database db;
  const accountID = "a123";
  late final DBPropertiesReader reader;

  test("work with properties", () async {
    getDBPath = () async => inMemoryDatabasePath;
    databaseFactory = databaseFactoryFfi;
    db = await getDB();
    reader = DBPropertiesReader(db);

    // Removes any temp data used for UI development.
    await db.delete(accountTable);
    await db.delete(propertyTable);

    await db.insert(accountTable, {
      "id": accountID,
    });

    var properties = await reader.read();
    expect(properties.isEmpty, isTrue);

    await db.insert(propertyTable, {
      "id": "p123",
      "account": accountID,
      "name": "VB Farm",
      "kind": PropertyKind.storage.string,
    });

    final huh = await db.query(propertyTable);

    properties = await reader.read();
    expect(properties.length, 1);
    final [prop] = properties;
    expect(prop.accountID, accountID);
    expect(prop.id, "p123");
    expect(prop.name, "VB Farm");
    expect(prop.kind, PropertyKind.storage);
  });
}

If the variable Database db is marked as late, the debugger will only stop on lines before the initialization of the db variable. Removing late allows breakpoints to stop anywhere in that file and other invocation points.

[derekxu16]

I investigated @osaxma's example above, and here's what I've found:

When setting a breakpoint on the final xd = x.toDouble(); line, ResolveBreakpointPos wants to set the breakpoint at the safepoint that is closest to the start of the line:

sdk/runtime/vm/debugger.cc

Lines 2018 to 2019 in ed18424

	// First pass: find the safe point which is closest to the beginning
	// of the given token range.

It picks the token corresponding to x, but it looks like it should really be picking the token two positions to the right, which corresponds to the t in toDouble().

@aam, do you have any thoughts about how we can fix this?

[aam]

It might be that the issue is with kernel->flowgraph construction around final variables initialization - I would check what is going on with https://github.com/dart-lang/sdk/blob/main/runtime/vm/compiler/frontend/kernel_binary_flowgraph.cc#L2067

[aam]

Splitting the line in two

/* breakpoint here would miss */ final xd = x
  .toDouble();

and setting a breakpoing at .toDouble() works.
The reason for this is that late variables uses (use of x) have hidden exception-path logic that makes debugger to set a code breakpoint at that exception-path (https://github.com/dart-lang/sdk/blob/main/runtime/vm/compiler/frontend/kernel_binary_flowgraph.cc#L2087).
Splitting a line and setting a breakpoint at toDouble() skips that late-initialization logic.

[a-siva]

@liamappelbe can you create issues for the synthetic statement tagging that you are working on and link it to this issue.

[liamappelbe]

#54005

[aam]

#54005

It would be nice to confirm whether that issue talks about ignoring code for breakpoints at the same level of granularity as this issue.
This issue is about "We prefer the lowest compiled code address" coded in

sdk/runtime/vm/debugger.cc

Line 1998 in 282bbce

static TokenPosition ResolveBreakpointPos(const Function& func,

. not being applicable to late vars initialization,