How to debug a stack trace that only contains Flutter classes

Help General
1

One of our tester manages to create grey screens by switching between apps and all I get in Sentry is this here.
Does anyone have an idea how I can narrow the piece of code inside our app that is the culprit?

TypeError: Null check operator used on a null value
  #0      Element.widget (package:flutter/src/widgets/framework.dart:3566)
  #1      Element.dependOnInheritedElement (package:flutter/src/widgets/framework.dart:4901)
  #2      Element.dependOnInheritedWidgetOfExactType (package:flutter/src/widgets/framework.dart:4909)
  #3      DefaultTextStyle.of (package:flutter/src/widgets/text.dart:169)
  #4      Text.build (package:flutter/src/widgets/text.dart:644)
  #5      StatelessElement.build (package:flutter/src/widgets/framework.dart:5687)
  #6      ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:5617)
  #7      Element.rebuild (package:flutter/src/widgets/framework.dart:5333)
  #8      StatelessElement.update (package:flutter/src/widgets/framework.dart:5693)
  #9      Element.updateChild (package:flutter/src/widgets/framework.dart:3941)
  #10      Element.updateChildren (package:flutter/src/widgets/framework.dart:4090)
  #11      MultiChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:7060)
  #12      Element.updateChild (package:flutter/src/widgets/framework.dart:3941)
  #13      Element.updateChildren (package:flutter/src/widgets/framework.dart:4090)
  #14      MultiChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:7060)
  #15      Element.updateChild (package:flutter/src/widgets/framework.dart:3941)
  #16      SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:6907)
  #17      Element.updateChild (package:flutter/src/widgets/framework.dart:3941)
  #18      Element.updateChildren (package:flutter/src/widgets/framework.dart:4090)
  #19      MultiChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:7060)
  #20      Element.updateChild (package:flutter/src/widgets/framework.dart:3941)
  #21      SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:6907)
  #22      Element.updateChild (package:flutter/src/widgets/framework.dart:3941)
  #23      ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:5642)
  #24      Element.rebuild (package:flutter/src/widgets/framework.dart:5333)
  #25      BuildScope._tryRebuild (package:flutter/src/widgets/framework.dart:2693)
  #26      BuildScope._flushDirtyElements (package:flutter/src/widgets/framework.dart:2752)
  #27      BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:3048)
  #28      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:1162)
  #29      RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:468)
  #30      SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1397)
  #31      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1318)
  #32      SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:1176)
  #33      _rootRun (dart:async/zone.dart:1399)
  #34      _CustomZone.run (dart:async/zone.dart:1301)
  #35      _CustomZone.runGuarded (dart:async/zone.dart:1209)
  #36      _invoke (dart:ui/hooks.dart:314)
  #37      PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:419)
  #38      _drawFrame (dart:ui/hooks.dart:283)
2

I think I’ve seen this before. Imho it may be related to the context being null when calling setState, I think it doesn’t do the type check but uses ‘!’ somewhere

3

any idea how to find the source?

4

This is probably from missing a context.isMounted somewhere. Is this error not being reproduced when you switch apps in debug mode?

5

Unfortunately no, I am not able to reproduce while debugging

6

It shouldn’t be too hard to find the null check that’s problematic. Did the tester say where it happened? What I can tell from the output it might be a null check in a Text widget.

7

Luckily we could find the issue finally, some exception elsewhere lead to a null context, but it would be good if we had better debugging possibilities in such cases

8

Use use_build_context_synchronously | Dart and NEVER use ! (too bad there isn’t a linter for !).

What we really need is a better linter (especially one that can be set to throw compile-time errors instead of warnings or infos).

9

The problem was an not handled exception in the asynchronous gap.

10

But I guess you had an ! somewhere where it got the null? It’s a nice bypass, it’s easy to get comfortable with it.

11

No, if you look at the stack trace the ‘!’ is deep inside the Flutter framework. The context just wasn’t valid anymore because of a previous other exception

12

That happened to me yesterday (and it was not about unmounted context nor !, as I mentioned).

What I did was:

A button in a widget opened a popup. Instead of using the context from the popup build method, I used the this.context to pop the popup (Navigator.pop(context, value)). It was mounted, but it triggered the same error you faced =(

So, forget what I said earlier, the linter we need is: “Are you using the correct context?”

1 Like
13

Yeah, although I am not sure that the linter can detect if we use the wrong context because it might be intentional.
It would be great to have more debug information in the exceptions to know which part of your own code was involved @CraigLabenz