Debugger breaks in sdk code, when assert is thrown, despite having enabled only "Debug my code"

The debugger breaks at an assertion, despite having debugging sdk and libraries disabled. Don't know if this issue is related to dart code or something else, but post it here anyways.

Dart-Code-Log-2021-11-03 17-11-59.txt

Bildschirmaufnahme.2021-12-01.um.17.11.53.mov

Ahh, and I have only "Uncaught Exceptions" enabled. Not all exceptions.

Can you click the "Load all stack frames" link when this happens and see what's in the call stack? (expand it as much as you can to get the full stack)

I think this could happen if we find no "user code" in the stack. When you disable debugging in the SDK, it doesn't prevent pausing on an exception in the SDK, it just means that you would usually pause further up the stack in the user code. However, if there is no user code in the stack that we can jump to, I think it may just break on the top frame.

If you know how I can reproduce this in a new app, I could debug it a little more. If it's the above, there's probably nothing we can do - but if there is user code in the stack (and we're just failing to handle it correctly), it should be fixable.

Thanks!

Logs to the video:
Dart-Code-Log-2021-11-04 13-52-53.txt

Steps to reproduce:

Create a new Flutter Project
Replace MyHomePage with:

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      // This call to setState tells the Flutter framework that something has
      // changed in this State, which causes it to rerun the build method below
      // so that the display can reflect the updated values. If we changed
      // _counter without calling setState(), then the build method would not be
      // called again, and so nothing would appear to happen.
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    // This method is rerun every time setState is called, for instance as done
    // by the _incrementCounter method above.
    //
    // The Flutter framework has been optimized to make rerunning build methods
    // fast, so that you can just rebuild anything that needs updating rather
    // than having to individually change instances of widgets.
    return Scaffold(
      appBar: AppBar(
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        title: Text(widget.title),
      ),
      body: Center(
        // Center is a layout widget. It takes a single child and positions it
        // in the middle of the parent.
        child: Column(
          // Column is also a layout widget. It takes a list of children and
          // arranges them vertically. By default, it sizes itself to fit its
          // children horizontally, and tries to be as tall as its parent.
          //
          // Invoke "debug painting" (press "p" in the console, choose the
          // "Toggle Debug Paint" action from the Flutter Inspector in Android
          // Studio, or the "Toggle Debug Paint" command in Visual Studio Code)
          // to see the wireframe for each widget.
          //
          // Column has various properties to control how it sizes itself and
          // how it positions its children. Here we use mainAxisAlignment to
          // center the children vertically; the main axis here is the vertical
          // axis because Columns are vertical (the cross axis would be
          // horizontal).
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SingleChildScrollView(
                child: SingleChildScrollView(
              child: Column(
                children: [
                  Expanded(
                    child: Text(
                      'You have pushed the button this many times:',
                    ),
                  ),
                ],
              ),
            )),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ), // This trailing comma makes auto-formatting nicer for build methods.
    );
  }
}

Start the app

Bildschirmaufnahme.2021-12-02.um.13.52.43.mov

It does look like when this exception occurs, there's no user code in the stack:

So I think it's working as expected. Although it's worth nothing that in the past many errors that the Flutter framework handled would be treated as "caught" (because technically, they were) but that made it difficult to use the debugger to track them down so now Flutter's error handling code is tagged to prevent them being considered caught.

Hmm, any option to get back to the old behavior, so that they errors like unbounded constraint and asserts and stuff go back to the console?

We for example, have an unbounded constraint during a 100ms animation, we decided not to fix for now, because as a user you can't see it. Now everytime we execute the animation it the debugger stops.

I think you'd have to untick Break on Uncaught Exceptions. The change is in the Dart+Flutter SDKs and I don't think it can be toggled - if the code is throwing exceptions that are generally considered uncaught, I think the new behaviour makes sense. Presumably it's a common case that exceptions are being thrown that should be ignored (for one, I guess it'll keep filling up the debug output with junk?).

I can vaguely remember, that read something about this change, but I can't find it. Might, you be so kind and link the issue where is change was discussed, they must have considered this in their decision-making process and I would love to understand their reasoning.

The main issue is at flutter/flutter#17007, although I suspect there may also be some discussion dotted around other issues (this, and the opposite issue where the debugger would break on exceptions that would actually be handled, have come up a fair bit).

This issue has been marked stale because it is tagged awaiting-info for 20 days with no activity. Remove the stale label or comment to prevent the issue being closed in 10 days.

This is back again. Ie. it breaks on retrow in the Image.network if the image gets a 404 even though there is an error function on Image.Network to handle specifically those cases.

@JohnGalt1717

@JohnGalt1717 sorry for the delay. Could you file an issue with some example code I can use to try to reproduce and debug? A log file (captured with Dart: Capture Debugging Logs) would be useful too, in case I can't reproduce.

Navigation Menu

Repository navigation

Debugger breaks in sdk code, when assert is thrown, despite having enabled only "Debug my code" #3702

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Debugger breaks in sdk code, when assert is thrown, despite having enabled only "Debug my code" #3702

Description

Activity

HerrNiklasRaab commented on Dec 1, 2021

DanTup commented on Dec 1, 2021

HerrNiklasRaab commented on Dec 2, 2021

DanTup commented on Dec 2, 2021

HerrNiklasRaab commented on Dec 2, 2021

DanTup commented on Dec 2, 2021

HerrNiklasRaab commented on Dec 3, 2021

DanTup commented on Dec 3, 2021

github-actions commented on Dec 24, 2021

JohnGalt1717 commented on Apr 13, 2022

DanTup commented on Apr 20, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions