You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
setState called when widget is not mounted on MultiFrameImage emitter #71344
customer:money is rarely seeing this crash (14 times within 4 weeks):
Thread 0 main thread_CastError: Null check operator used on a null value
at State.setState(framework.dart:1289)
at _ImageState._handleImageFrame(image.dart:1188)
at ImageStreamCompleter.setImage(image_stream.dart:616)
at MultiFrameImageStreamCompleter._emitFrame(image_stream.dart:946)
at MultiFrameImageStreamCompleter._decodeNextFrameAndSchedule(image_stream.dart:925)
at <asynchronous gap>(async)
Seems like there's a race between image frames being emitted and the widget being disposed.
We could add some more defensive code before calling setState, but we should be doing everything correctly here and I'd like to understand better why this is happening.
In ImageState.dispose, we're unsubscribing from the stream. That should prevent further calls to _handleImageFrame.
The only thing I can think of is if we're somehow leaving a stray listener on the stream, but we shouldn't be.
We don't have repro unfortunately. It happens rarely in the wild (i.e. release mode). If nothing jumps out at you, we can close this. If the crash rates increase, we can revisit and hopefully have a repro.
We could defensively add a mounted check but it'd be really nice to either know we can't avoid it because of async something messing it up (I can't see anything that would) or that we should remove it when we figure out what the real bug is.
Activity
goderbauer commentedon Dec 9, 2020
/cc @dnfield
dnfield commentedon Dec 9, 2020
I assume this is happening in non-debug modes? There are asserts higher up that should be triggered if it were to happen when asserts are enabled.
dnfield commentedon Dec 9, 2020
We could add some more defensive code before calling setState, but we should be doing everything correctly here and I'd like to understand better why this is happening.
In
ImageState.dispose, we're unsubscribing from the stream. That should prevent further calls to_handleImageFrame.The only thing I can think of is if we're somehow leaving a stray listener on the stream, but we shouldn't be.
It'd really help to have a reproduction for this.
mehmetf commentedon Dec 11, 2020
We don't have repro unfortunately. It happens rarely in the wild (i.e. release mode). If nothing jumps out at you, we can close this. If the crash rates increase, we can revisit and hopefully have a repro.
mehmetf commentedon Dec 11, 2020
On second thought, let's keep it open since closing this will also close the internal bug.
dnfield commentedon Dec 11, 2020
We could defensively add a mounted check but it'd be really nice to either know we can't avoid it because of async something messing it up (I can't see anything that would) or that we should remove it when we figure out what the real bug is.