Develop Reference

Fixing OutOfMemoryErrors

Hello everyone I am seeing a major uptick in crashes regarding memory leaks in our recent Android builds. We have done some things to try to mitigate these issues, but still am seeing the same crashes in the latest release.
Fatal Exception: java.lang.OutOfMemoryError
Failed to allocate a 16 byte allocation with 1890136 free bytes and 1845KB until OOM, target footprint 201326592, growth limit 201326592; failed due to fragmentation (largest possible contiguous allocation 54788096 bytes)
java.lang.Long.valueOf (Long.java:845)
io.reactivex.internal.operators.observable.ObservableInterval$IntervalObserver.run (ObservableInterval.java:82)
io.reactivex.Scheduler$PeriodicDirectTask.run (Scheduler.java:562)
io.reactivex.Scheduler$Worker$PeriodicTask.run (Scheduler.java:509)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run (ExecutorScheduler.java:288)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run (ExecutorScheduler.java:253)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
java.lang.Thread.run (Thread.java:923)
Fatal Exception: java.lang.OutOfMemoryError
Failed to allocate a 16 byte allocation with 1590248 free bytes and 1552KB until OOM, target footprint 201326592, growth limit 201326592; failed due to fragmentation (largest possible contiguous allocation 39845888 bytes)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.schedule (ExecutorScheduler.java:161)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.schedule (ExecutorScheduler.java:187)
io.reactivex.Scheduler$Worker$PeriodicTask.run (Scheduler.java:531)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run (ExecutorScheduler.java:288)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run (ExecutorScheduler.java:253)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
java.lang.Thread.run (Thread.java:923)
Fatal Exception: java.lang.OutOfMemoryError
Failed to allocate a 16 byte allocation with 1215008 free bytes and 1186KB until OOM, target footprint 201326592, growth limit 201326592; failed due to fragmentation (largest possible contiguous allocation 49020928 bytes)
io.reactivex.internal.queue.MpscLinkedQueue.offer (MpscLinkedQueue.java:62)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.schedule (ExecutorScheduler.java:167)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.schedule (ExecutorScheduler.java:187)
io.reactivex.Scheduler$Worker$PeriodicTask.run (Scheduler.java:531)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run (ExecutorScheduler.java:288)
io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run (ExecutorScheduler.java:253)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
java.lang.Thread.run (Thread.java:923)
is there some framework change that is triggering these issues, is this application code that is causing this? what are some strategies to try to address crashes like the above?

Some other techniques to consider beyond the existing comments:
In field instrumentation:
Activity Patterns: If you have something that records user activity, look for apps that go a long time without crashing and apps that crash earlier and see if there are different actions performed by the user
Direct Memory Usage: Since you are not yet able to reproduce this on debug builds, you could record memory available just before and just after particular activities to help you narrow down where in the app this occurring. You can access app available memory and then log it (if you can get the logs) or report it back through some analytics system.
Local testing:
(with Leak Canary or profiler)
There are often points in time that should come back to the same level of allocated memory: for instance if you go into a screen and come back out you may allocate some static items, but from 2nd use of the screen onwards you will want the memory to come back to a normal (quiescent) point. So stopping execution, forcing a GC, restarting execution and going through a workflow and then coming back to the home screen. (again skipping the first time) Can be a good way to narrow down which workflow is leaving significant extra memory.
It is unusual that the debug builds are not producing this effect, if you have a "friendly" end user reporting this issue, perhaps give them a debug build and ask them to support you by using it.
In a debug environment you can also try to "make it worse" so, for example, go into and out of a screen or workflow 10 or 100 times (scripting for the 100 example).

Use Coroutines for long or heavy operations. These crashes are coming from Rxjava. Maybe you are not performing work accurately in that.

I am just going to have a stab at where you could look, from the stack trace it looks like you are using a schedular to perform tasks. My suspicion is that you are running multiple threads, and as each thread requires its own allocation of memory some thing to consider would be:
Controlling the number of threads through a thread pool, this will cap the number of threads available and recycle threads instead of allocating new ones and potentially having a significant number of threads running at the same time.

android ndk - strange OutOfMemory error without memory leak

I'm working at a pdf reader app by using the native library from muPDF. Unfortunately I'm encountering an OOM error after a lot of swiping through the pages. I'm using the following code to get some insights in the memory behavior (I've also used the Android Device Monitor before):
Runtime.getRuntime().totalMemory() // amount of allocated memory in the app heap
Debug.getNativeHeapAllocatedSize() // amount of allocated memory in the native heap
Now comes the strange thing...due swiping through the pages the returned values of these to methods are always stable, so actually it doesn't look like there would be a memory leak at all. But after some time an OOM error occurs although the values of these two methods are still like at the beginning.
Does anyone know what is happening here?

You can try to prevent OutOfMemoryError from occurring by adding this in your application tag in your AppManifest.xml:
android:largeHeap="true"

Android program crash on random error (caused by java.lang.OutOfMemoryError)

My program runs just fine and then I always encounter a random crash error (eg. Error inflating class ) which is almost always started by a OutOfMemoryError.
I watched my VM Heap in DDMS and it looks like gc is doing it's job as I'll watch the %used go up and down along with the #Objects
I've noticed that I get the crash when I have close to these stats:
Heap Size 11.820 MB
Allocated 7.020 MB
Free 4.801 MB
% Used 59.39%
# Objects 148,927
This is about the peak of usage on the device. Sometimes it crashes here, but other times it allows me to move around to another category which allows GC to do it's work getting the %used down to 32%. However, I usually crash shortly after even though usage is down.
I typically crash out with a chain of errors. The top-most Caused by: error is usually something like Caused by: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I'm not sure where to go next as the device seems fine on resources when it crashes, but complains about not having enough memory. I've tried running the program without images and I still get an app that crashes. Regardless, where should I start looking to find the culprit?
** EDIT **
Kindle Fire on Android 2.3.4 via Eclipse

In pre-honeycomb android versions bitmap data stores outsize VM heap, so its impossible to track bitmap data via DDMS :)
There are two possible reasons:
1. Your interface use giant count of images
2. You create bitmaps manually and memory leak occurs. In one Google IO presentation was said that several garbage collections necessary to completely free bitmap memory
Sorry, missed that app crashed without images. Try dump memory usage periodically and see it later via Eclipse Memory Analyzer

what shoud be difference between "NativeHeapAllocatedSize" and "Runtime totalMemory" in Android to prevent from "OutOfmemory Exception"?

hello i m doing some runtime calculation for getting NativeHeap memory and allocated memory at runtime, so any one can suggest me
what should be the difference between "Debug.getNativeHeapAllocatedSize()" and "Runtime.getRuntime().totalMemory()"
so can prevent app by OutOf Memory Exception.
Thanks

Runtime.getRuntime().totalMemory()
Returns the total amount of memory which is available to the running program.
getNativeHeapAllocatedSize()
For devices below HoneyComb most of the huge allocations are deferred to the native heap (e.g Bitmaps). Hence this api is useful to find out how much of native heap is allocated.
OOM Errors occurs when there are no objects which can be freed by the DVM. Typically you have about 16MB in the Heap to play with (for a standard phone). Check your logs* to see GC statements having info about how much of memory is allocated.
I don't think there should be a fixed ratio to cause an OOM error. Like in the case when you load a very huge bitmap, here the native memory used is huge.
Slide 25

External allocation too large for this process in Android

I'm getting "external allocation too large for this process" errors in my app. Lots of these at once:
11-16 10:56:59.230: ERROR/dalvikvm-heap(2875): 1303680-byte external allocation too large for this process.
11-16 10:56:59.230: ERROR/GraphicsJNI(2875): VM won't let us allocate 1303680 bytes
11-16 10:56:59.230: ERROR/dalvikvm-heap(2875): 1536000-byte external allocation too large for this process.
11-16 10:56:59.230: ERROR/GraphicsJNI(2875): VM won't let us allocate 1536000 bytes
It appears that they are produced while the layout is being rendered, after loading large bitmaps. The errors, however, are not produced while the bitmap is being decoded.
How can I debug these errors? Any additional pointers?

adamp's comment was the answer in my particular case:
The framework will often capture views
onscreen into temporary bitmaps for
drawing performance. It looks like
your app is pushing right up against
its memory limit already and this
bumps it over. Take a look at the
other suggestions for limiting your
app's memory usage.

If you're using threads, then the debugger might be the source of the problem. If you run the app under the debugger, then any threads created will still be retained by the debugger, even when they're finished running. This leads to memory errors that won't occur when the app is running without the debugger.
http://code.google.com/p/android/issues/detail?id=7979