Android app crashes with WIN DEATH after memory-intensive activity

Question

Summary

I work on an Android app which, as one of its features, involves users marking up an image and saving it. This process involves some heavy canvas drawImage() calls (sometimes on an image around 12 MB+ uncompressed) as well as lots of encoding and decoding of data. The image data also cached in the Android file system and passed from Java to JavaScript through a JavaScriptInterface.

However, with an LG G Pad X8.3 running Android 5.0.2, we are getting lots of crashing. When it crashes, the log says "WIN DEATH" and it goes back to the home screen without showing any "Unfortunately, ___ has stopped" message. Our "WIN DEATH" is preceded by a win death of the InputMethod and before that a "WIN DEATH" of com.lge.launcher2.Launcher. It is intermittent, but frequent enough to be a big problem.

Details

(1) It seems to happen after the heavy image saving manipulation, but not immediately after

(2) It happens more often when the keyboard is brought up. Is something about bringing up the keyboard causing it to crash?

(3) When watching the memory usage in Android Studio as the app is running, nothing is too out of the ordinary. When it crashes, there is still free memory available in the graph.

(3) We tried using largeHeap in our manifest, but that did not eliminate the crashing.

(4) Memory usage is between 10 and 20 MB.

(5) I can add around 32 million numbers to a JavaScript array before the web view crashes. That's at least 240 MB (8 bytes per JS number). When it crashes, it shows a blank screen, as opposed to the crash I am trying to fix where it brings you back to the home screen.

(6) There is a well publicized memory leak (or a couple, actually) in this version of Android, but LG does not offer upgrades for this model.

(7) We have tried optimizing the code to use as little memory as possible, but the crashing remains.

(8) The crash logs always contain similar information around the crash.

02-08 12:13:01.642    1850-1850/? I/PhoneApp﹕ onTrimMemory: 5
02-08 12:13:01.642    1850-1850/? I/PhoneApp﹕ trim memory
02-08 12:13:01.652      945-965/? I/ActivityManager﹕ Process com.google.android.partnersetup (pid 23908) has died
02-08 12:13:01.682    945-16584/? I/ActivityManager﹕ Process com.google.android.apps.plus (pid 23756) has died
02-08 12:13:01.692    1850-1850/? I/PhoneApp﹕ onTrimMemory: 10
02-08 12:13:01.692    1850-1850/? I/PhoneApp﹕ trim memory
02-08 12:13:01.712     945-2088/? I/ActivityManager﹕ Process com.lge.p2p (pid 24102) has died
02-08 12:13:01.742     945-2041/? I/ActivityManager﹕ Process com.google.android.gms.wearable (pid 23833) has died
02-08 12:13:01.752    1850-1850/? I/PhoneApp﹕ onTrimMemory: 15
...
02-08 12:11:06.862  22936-22936/com.mycompany.ourapp W/IInputConnectionWrapper﹕ getTextBeforeCursor on inactive InputConnection
...
02-08 12:11:06.912  20890-20890/? D/Cliptray Manager﹕ isAvailable() UserHandle.myUserId() = 0, isOwner = true
02-08 12:11:06.912    1961-8134/? I/Cliptray Service﹕ Standard mode!! ClipTray is Supported!
02-08 12:11:06.912    1961-8134/? D/Cliptray Service﹕ isAvailable() mLastIsOwner = true
02-08 12:11:06.912    1961-8134/? I/Cliptray Service﹕ Owner!! ClipTray is Supported! mIsOwnerClipTray = true
02-08 12:11:06.912    1961-8134/? D/Cliptray Service﹕ ignore packageName : com.mycompany.ourapp
...
02-08 12:12:39.782  22936-22936/com.mycompany.ourapp I/Choreographer﹕ Skipped 35 frames!  The application may be doing too much work on its main thread.
...
02-08 12:13:02.622     945-2086/? I/WindowState﹕ WIN DEATH: Window{8dce4a3 u0 com.lge.launcher2/com.lge.launcher2.Launcher}
...
02-08 12:13:02.872     945-1922/? I/WindowState﹕ WIN DEATH: Window{393167d2 u0 InputMethod}
...
02-08 12:13:03.052    1979-1979/? D/QC_RIL_OEM_HOOK﹕ The connection to the service got disconnected unexpectedly!
02-08 12:13:03.052    1961-1961/? D/QC_RIL_OEM_HOOK﹕ The connection to the service got disconnected unexpectedly!
02-08 12:13:03.052    1850-1850/? D/QC_RIL_OEM_HOOK﹕ The connection to the service got disconnected unexpectedly!
02-08 12:13:03.052    1850-1850/? D/QC_RIL_OEM_HOOK﹕ The connection to the service got disconnected unexpectedly!
02-08 12:13:03.072      945-945/? W/InputMethodManagerService﹕ Session failed to close due to remote exception
    android.os.DeadObjectException
            at android.os.BinderProxy.transactNative(Native Method)
            at android.os.BinderProxy.transact(Binder.java:496)
            at com.android.internal.view.IInputMethodSession$Stub$Proxy.finishSession(IInputMethodSession.java:305)
            at com.android.server.InputMethodManagerService.finishSessionLocked(InputMethodManagerService.java:1463)
            at com.android.server.InputMethodManagerService.clearClientSessionLocked(InputMethodManagerService.java:1454)
            at com.android.server.InputMethodManagerService.clearCurMethodLocked(InputMethodManagerService.java:1480)
            at com.android.server.InputMethodManagerService.onServiceDisconnected(InputMethodManagerService.java:1499)
            at android.app.LoadedApk$ServiceDispatcher.doDeath(LoadedApk.java:1391)
            at android.app.LoadedApk$ServiceDispatcher$RunConnection.run(LoadedApk.java:1405)
            at android.os.Handler.handleCallback(Handler.java:739)
            at android.os.Handler.dispatchMessage(Handler.java:95)
            at android.os.Looper.loop(Looper.java:135)
            at com.android.server.SystemServer.run(SystemServer.java:302)
            at com.android.server.SystemServer.main(SystemServer.java:203)
            at java.lang.reflect.Method.invoke(Native Method)
            at java.lang.reflect.Method.invoke(Method.java:372)
            at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:908)
            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:703)
...
02-08 12:13:03.132     945-2088/? I/ActivityManager﹕ Process com.google.process.gapps (pid 21317) has died
...
02-08 12:13:03.182    1405-1405/? D/LGKeyguardUnlockMethodController﹕ onTrustChanged with userId : 0 , getUserTrustIsManaged : false ,getUserHasTrust : false
...
02-08 12:13:03.452     362-1705/? V/AudioFlinger﹕ 22936 died, releasing its sessions
02-08 12:13:03.452     362-1705/? V/AudioFlinger﹕ pid 1850 @ 0
02-08 12:13:03.452     362-1705/? V/AudioFlinger﹕ pid 22936 @ 1
02-08 12:13:03.452     362-1705/? V/AudioFlinger﹕ removing entry for pid 22936 session 520
02-08 12:13:03.452     362-1705/? V/AudioFlinger﹕ purging stale effects
02-08 12:13:03.452     362-1705/? V/AudioFlinger﹕ remove track (4097) and delete from mixer
02-08 12:13:03.452     945-2086/? I/WindowState﹕ WIN DEATH: Window{3eafa2d1 u0 com.mycompany.ourapp/com.mycompany.ourapp.MainActivity}

The memory leak that may be partially responsible: https://code.google.com/p/android/issues/detail?id=79729

Question

What could be causing the app to crash in this way? Is it a memory issue? is anything in the log output that I've copied here relevant?

Has anyone else had this problem and solved it? Is the Android 5.0.x/1.x memory leak bug responsible?

I wish I could be more specific, but the code is proprietary and the problem isn't (or hasn't yet been) localized to any one particular code sample. If more information is needed about a particular issue, please ask.

Update

I've noticed that there are a bunch of Choreographer messages in the logs about it doing too much work, but they are relatively small frame skips (~ 35 frames) and the last message occurs a full 20 seconds before the app crashed.

Update 2-10-16

We are now trying to reuse canvas objects in case they are not garbage collected, and we are also calling System.gc() when onTrimMemory is called with TRIM_MEMORY_RUNNING_LOW. This seems to have reduced the crashing to some degree, but still frequently enough to be concerning. Most of all, I would like to understand why it seems to randomly use up too much memory and crash. I've added the onTrimMemory lines to the log output below, which show it going from low to critical in a span of 100 ms. If this only happened when actually performing the memory-intensive actions, that would make sense, but it happens sometimes long after the user process has finished.

Answer 1

Pulling my hair out over here, trying to get a HTML Canvas based application running in CrossWalk on a Fire TV Stick. The app would run fine then crash after 30 minutes of use with this error. I was able to fix it but my use case is pretty specific, either way it may help folks who show up here later.

TL;DR: Reduce the size of textures being loaded into and out of the GPU.

I had a fullscreen canvas element running PixiJS, working essentially as a slideshow. The problem came from a single slide type, where large images with transparency would animate over a fixed background. After logging the CPU/GPU usage in Chrome's timeline feature I could see that the textures were being loaded into and out of the GPU all the time to accomplish the affect. Ultimately, I was able to resolve the issue by completely removing the background image element from canvas, and just displaying it in a div behind the canvas. The affect was identical, but the performance was improved significantly and this problem disappeared afterwards.

Answer 2

You are dealing with large bitmaps and loading all of them at run time. You have to deal very carefully with large bitmaps by loading the size that you need not the whole bitmap at once and then do scaling.

Huge JavaScript Cause This

Given that you are working with limited memory, ideally you only want to load a lower resolution version in memory. The lower resolution version should match the size of the UI component that displays it. An image with a higher resolution does not provide any visible benefit, but still takes up precious memory and incurs additional performance overhead due to additional on the fly scaling.

Please check Managing Bitmap Memory.

You are using lots of canvas at once that's why this problem .

Answer 3

This used to happen with me, even after i used the large heap attribute in application manifest and it stopped to happen when i reset all the variable to null after finishing using them.

I don`t know your code but i would advise you to re-use the same variables and make sure you clean up after every operation and when done, because keeping in the memory large unused files is not good.