Engine does not handle OOM well

When we run out of memory, we just crash. There's no clear indication of what the problem is. flutter run just says the application finished after printing W/ActivityManager: Force finishing activity com.yourcompany.foo/org.domokit.sky.shell.SkyActivity a couple of times, but doesn't quit. On the device, Android shows a material dialog that says "foo has stopped" with a single button "Open app again".

Here's an app that demonstrates the problem:

import 'package:flutter/widgets.dart';

void main() {
  runApp(new CustomPaint(painter: new Painter()));
}

class Painter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    final Paint paint   =   new Paint()
      ..color = const Color(0xFFEE9944);
    while (true)
      canvas.drawRect(new Rect.fromLTWH(10.0, 10.0, 10.0, 10.0), paint);
  }
}

Ideally we'd dump a stack trace of the currently running Dart code, at least.

There are a couple other bugs about crash reporting, see #614 and flutter-team-archive/gallery#633. We likely will need a little assistance from the Dart runtime, at least in AOT mode.

In this case, mobile OSes provide a bunch of memory callbacks we should be listening too, and probably telling the Dart VM about. I suspect we don't get much chance when we get killed from this to print a stack however.

Chrome also had a specific OutOfMemory() function which the allocator would call to make crash-stacks caused by OOMs very explicit. I don't know if Dart's allocator has such or not, but once we start collecting more crash stacks from the wild, we may want something like that.

@turnidge

(I'm studying how flutter users diagnose and fix memory problems, so I'm following this bug - @turnidge)

We definitely need to improve this, but it's not a current priority.

@Hixie

Looks like there's a few related issues to this that have been closed. It's unclear to me what the scope of the bug should be right now.

There could be a very basic patch addressing this that just adds a warning log whenever Flutter gets a memory pressure signal. That would at least help devs diagnose the problem a bit when it happens, but would be noise in some cases and wouldn't give a full stack trace in actual crashes.

As far as I've been able to tell the engine doesn't have any kind of uncaught exception handling set up right now, and I think it would probably need it to be able to respond to OOM crashes specifically. Flutter itself can integrate with Sentry (#614) but I don't think that works for this since OOM exceptions aren't caught. Is that engine handling something we want to build? Couldn't find any existing issues, but may have missed something.

/cc @Hixie @yjbanov

This sounds like a neat feature. Hope it's still being looked at.

Navigation Menu

Repository navigation

Engine does not handle OOM well #6500

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Engine does not handle OOM well #6500

Description

Activity

eseidelGoogle commented on Oct 25, 2016

eseidelGoogle commented on Feb 17, 2017

turnidge commented on Sep 26, 2017

Hixie commented on Dec 19, 2017

mklim commented on Sep 26, 2018

12 remaining items

larssn commented on Feb 12, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions