App crashing when workload is too heavy

[emshack]

Steps to Reproduce

In my application, I need to perform an arbitrarily high number of list add operations in a row. However, when I try to run this on a large enough number (threshold seems to be above 7 million and under 14 million), my app crashes (full crash logs below). Am I hitting a limit somewhere, and if so, is there a way to get around this? Should I be running this part of the code in a separate thread?

Flutter Doctor

[✓] Flutter (on Linux, channel alpha)
• Flutter at /usr/local/google/home/emshack/vanadium/flutter
• Framework revision d5deea4 (17 hours ago), engine revision ce3b454
[✓] Android toolchain - develop for Android devices (Android SDK 23.0.2)
• Android SDK at /usr/local/google/home/emshack/Android/Sdk
• Platform android-23, build-tools 23.0.2
• OpenJDK Runtime Environment (build 1.8.0-google-v7-114555630-114530017)
[✓] Atom - a lightweight development environment for Flutter
• Atom installed; Flutter plugin version 0.2.1

Logs and Crash Reports

W/ActivityManager: Scheduling restart of crashed service com.rsupport.mvagent/com.rsupport.android.push.service.RSPushService in 1000ms
W/ActivityManager: Scheduling restart of crashed service com.rsupport.mvagent/.service.WebViewerService in 11000ms
W/ActivityManager: Scheduling restart of crashed service com.facebook.katana/com.facebook.mqttlite.MqttService in 20569ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.googlequicksearchbox/com.google.android.apps.gsa.eventlogger.EventLoggerService in 30567ms
W/ActivityManager: Scheduling restart of crashed service com.facebook.orca/com.facebook.mqttlite.MqttService in 30566ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME in 1000ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.location.nearby.direct.service.NearbyDirectService in 37161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/.auth.trustagent.GoogleTrustAgent in 37161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.reporting.service.DispatchingService in 47161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.geofencer.service.GeofenceProviderService in 47161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.internal.server.GoogleLocationService in 57161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.network.NetworkLocationService in 67161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.contextmanager.service.ContextManagerService in 77161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/.gcm.GcmService in 87161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.geocode.GeocodeService in 97161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.internal.PendingIntentCallbackService in 107161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/.common.stats.GmsCoreStatsService in 117161ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/.deviceconnection.service.DeviceConnectionServiceBroker in 127160ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.internal.GoogleLocationManagerService in 137160ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/.nearby.messages.service.NearbyMessagesService in 147160ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/.backup.BackupTransportService in 147160ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.internal.server.HardwareArProviderService in 157160ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.gms/com.google.android.location.fused.FusedLocationService in 167160ms
W/ActivityManager: Scheduling restart of crashed service com.google.android.googlequicksearchbox/com.google.android.voiceinteraction.GsaVoiceInteractionService in 1000ms
W/ActivityManager: Force removing ActivityRecord{15d51d8 u0 com.example.my_app/org.domokit.sky.shell.SkyActivity t2618}: app died, no saved state
W/System.err: bgo: Maintenance In Progress
W/System.err: at ctk.C(HttpClient.java:1236)
W/System.err: at ctk.a(HttpClient.java:566)
W/System.err: at ctk.a(HttpClient.java:135)
W/System.err: at ctk.b(HttpClient.java:307)
W/System.err: at bek.a(UserASP.java:199)
W/System.err: at bek.V(UserASP.java:134)
W/System.err: at azu.run(MVObserverReceiver.java:85)
W/System.err: at java.lang.Thread.run(Thread.java:818)

[eseidelGoogle]

Could your app be causing the device to run out of memory? I doubt that we're correctly responding to memory warnings from the OS. I'm surprised by all the crashed service logs in your adb logcat. We could look at the memory usage via Android tools or possibly via observatory on the device? FYI @jason-simmons @johnmccutchan

[emshack]

Yeah, this could definitely be the case.

[eseidelGoogle]

I'd start by looking at your app's memory usage via the settings app on the phone, or one of android's tools:
http://developer.android.com/tools/performance/comparison.html

Alternatively try the observatory button in atom. https://flutter.io/debugging/ is somewhat out of date and doesn't talk about memory debugging. But observatory (which runs on the device itself but you connect to from your host) can show you the Dart VM internals, including memory usage: https://dart-lang.github.io/observatory/

There is definitely work for flutter to do here, but I also think we need a bit more context of what's going on or some example code to debug ourselves if we want to move forward.

[eseidelGoogle]

Spoke with @emshack in person. Flutter isn't handling this case very well, I've filed #3006 to better track this. Unless you think there is more for flutter to do in this specific issue, I'm going to close.

[github-actions]

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 flutter doctor -v and a minimal reproduction of the issue.