App crashes when displaying specific widgets #36631
Comments
|
|
What version of Flutter was running in the app that generated this stack trace? I tried symbolizing the trace with engine commit |
|
Probably one version before v1.8.2-pre.118 |
|
This also happened on: Samsung Galaxy Note 5 |
p30arena
changed the title
|
This is another case, when using firebase_ml_vision on a KitKat device |
|
Another try on the KitKat device when pushing a simple page after working with the app (consuming some memory) |
|
might be related |
|
@jason-simmons |
|
Can you provide a code example that we could use to reproduce this locally? |
|
I think you need the whole project to reproduce the crash. I'm planning to provide the tombstones of those devices too. Might be related #36176 |
|
Didn't experience these errors on prev versions of flutter. again on face detection |
|
I found two pages that are prone to crash: These were working OK a month ago, these crashes are happening since last week or two. |
|
@jason-simmons @dnfield @GaryQian |
p30arena
changed the title
p30arena
changed the title
|
We need to know the hash of Flutter you're using so we can symbolicate these. Or, if you can symbolicate them that would be very helpful. |
|
engine.version 0861e0a doctor crash ndk-stack doesn't give me the full crash dump I followed: https://github.com/flutter/flutter/wiki/Crashes addr2line also gives ?? |
|
using the arm64 symbols for that hash, your first crash is happening in Same thing with the shorter crash. |
|
Do you have a sample app that reproduces this? What model phone? |
|
Samsung Galaxy Note 8.0 I have two versions of apks, one that won't crash (older release of flutter) and this one that crashes. |
|
I'm using CustomPainter in that widget.
and I'm passing a new instance of Paint to each function This is happening on other models too, This is happening on 3 days older version of flutter:
This is happening on Today's version of flutter: Samsung Galaxy Note 8.0 I can't reproduce the error on: Samsung A5 2016 . |
|
Can you create a small program using CustomPainter with the same calls to reproduce this? |
|
I couldn't reproduce it in a new app. 😩 But then I switched to the "stable" channel, now there are no crashes anymore. |
|
vmstat |
|
adb.exe shell "cat /proc/meminfo" BEFORE LAUNCH STARTUP BEFORE THE CRASH AFTER THE CRASH |
|
If I give the UI more time to render by delaying the result of FutureBuilder, the crash won't happen on the "Samsung Galaxy Note 8.0" as easy as before it did.
I'm giving this part more time to stay on the screen: now if I replace that line with: it is less likely to crash on the first try. on the last try, I ditched the FutureBuilder, It seems like it's an OOM, but nothing is thrown on the OS side. I'm also using these two additional lines in my manifest |
|
Instagram uses 30MB of memory while my app uses 170MB of memory 😮 |
|
TEST APP Filling memory with ByteData
TEST APP LargeHeap - Filling memory with ByteData
TEST APP Filling memory with int
TEST APP Mixing Dart + Native
MAIN App's Memory
|
|
Issues that can help this: "Example implementation of Image changes" #17614 I think something like EarlyEvictionImageService could help a lot. |
|
MAIN App's Memory After setting:
|
|
If the crash is due to memory usage, can you try patching your engine locally to reduce the Skia resource cache size? I had a patch to reduce that which had to be reverted because it wasn't working quite right. I'm working on relanding it. The relevant line is in shell/gpu/gpu_surface_gl.cc line 31, change 512 to something like 50. |
|
I'm going to follow the instructions here https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment UPDATE gclient sync |
|
My thoughts on these PRs: I think even on higher-end devices like Samsung S8 with 4GB of RAM, when the background applications are consuming some quality RAM, the cache set to 512 can cause an immediate crash. It might be due to the reason that OS can't free the Available Memory "fast enough" and provide it to the Skia, so egl* operations fail (like eglChooseConfig). If I postpone the displaying of data (with something like Future.delayed), the crash rates drop. . so then I'm thinking of changing the cache without patching the engine Is this line incorrect?
it never returns a result. . found another issue that might be related |
Theres another scenario that makes me to think that I was wrong, when the bg apps are consuming memory, setting cache to a higher value, preserves memory for the current app and prevents crashes related to egl* functions. After reviewing the memory tests, @dnfield I'm not familiar enough with this context though. |
|
The OS will kill your process before you come anywhere near using all the RAM the device has. Using 1gb on a 2gb device is probably enough to trigger an OOM as far as the app is concerned. |
Ok, but my app doesn't consume that much memory (stays around 170 to 400 after lowering the imageCache),
max cache size on the STABLE channel is 512, I experienced no crashes with this number before. |
|
Ok, I have a fresh crash dump for you 😄 engine.version 38ac5f3 . I thought the CPU is 32-bit but this is the custom ndk-stack result: https://github.com/dart-lang/sdk/blob/master/runtime/observatory/BUILD.gn#L325 🤔 |
|
I'm pretty confused at this point. What we really need to investigate this is a reproducible case. I understand you can't share your app's source code - and to be honest, that would be less helpful anyway. It would be very helpful if you could start peeling things away from your app until you have a minimal reliable reproduction of this crash that you could then share some source code for. If it's a particular Widget or draw call that causes this, that would be something we could work at fixing. Right now, we're getting very similar backtraces that aren't telling us enough of why or how things happened. |
|
First I'm going to give you this info, Then I'm going to narrow down my app to a button and that widget. I'll provide a Memory Analysis and a new Crash Dump (the Routine is different unless I'm doing it wrong - Routine $d.25 at hb-ot-shape-complex-myanmar.cc) I'm doing fast pushing and popping for about 7 times, then the app crashes. (sometimes it's not needed to repeat it, it crashes on the first push) '/lens_page': (context) => LensPage(PageStorageKey("lens_page")), Memory
Engine engine.version 38ac5f3 Stack Routines |
|
I narrowed down the app to a Splash page and a button after that. When the button pressed, a Scaffold is shown. after about 15 pushes&pops the app crashed. Memory
Stack bgImage is a dart:ui Image |
|
This still isn't quite reproducible - what is getImageFile? What is getIndicatorImageInfo? Is it enough to just allocate any old Image and call dispose on it in dispose? Are you reaching the dispose method at all? |
Yes I'm reaching the dispose method I'm going to give you a working project. First, choose an image from Gallery, then push the second button then pop, then push then pop for a couple of times till the crash. hello_egl_bug.zip. |
|
On some devices, it doesn't need repeated push&pop, crashes on the first push. |
|
I was able to reproduce this when running the hello_egl_bug app on a Nexus 7. It's likely related to some recent changes to how the engine decompresses images. Will continue investigating. |
jason-simmons
added a commit
to jason-simmons/flutter_engine
that referenced
this issue
Jul 31, 2019
…nvokes its callback SingleFrameCodec had been holding a persistent handle to the peer Dart object while waiting for the decoder callback. However, Dart code could call Codec.dispose during that interval, which would cause the Dart peer to drop its reference to the SingleFrameCodec and potentially delete the SingleFrameCodec. Fixes flutter/flutter#36631
jason-simmons
added a commit
to flutter/engine
that referenced
this issue
Jul 31, 2019
…nvokes its callback (#10297) SingleFrameCodec had been holding a persistent handle to the peer Dart object while waiting for the decoder callback. However, Dart code could call Codec.dispose during that interval, which would cause the Dart peer to drop its reference to the SingleFrameCodec and potentially delete the SingleFrameCodec. Fixes flutter/flutter#36631
|
The fix should be available on the Flutter master branch now. Thank you for the bug report and the reproduction! |
|
Thank you for the Quick Fix! |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Device: LG G5 H860
Android: 8
The text was updated successfully, but these errors were encountered: