I encountered an issue with a leak on the in android's native heap in my app. The leak seems to come from LinkedBlockingQueue that is just keep growing without being cleaned up.
If you look at the look below, the native heap has a total of 478M and it keeps growing (it started from 20M and it keeps growing by around 250k every few seconds). The JVM heap is working correctly and stays at a the same levels around 100M. My app uses its own network code but even with it turned off and the app just "sits" there it still have this leak.
I have identified that the LinkedBlockingQueues are point to an com.android.okhttp.ConnectionPool instance (the same one). I don't use okhttp anywhere in my code. I do use firebase with config, database and storage support. But with the exception of the config that has attached listener the other services are not while I'm testing.
The snapshot below shows my java heap dump. The LinkedBlockingQueue has 6029 instances and almost 300M of retained memory. This number grows with the native heap increase so I'm assuming they are related.
The snapshot below shows one of the LinkedBlockingQueue$Node instances where the item is the connection pool. They all look the same and pointing to the same item.
I never encountered a memory leak like that and not sure what is the reason for it. I would appreciate if any of you have any thoughts of what it could be or if you had an issue like that before.
I figured it out. This had nothing to do with my app or firebase. It seems that Android Studio with ADB Integration may have been the cause.
When I disable the integration and used Android Device Monitor for memory and getting the logs. The native heap doesn't grow and stays at around the same levels.
Related
I've been trying to solve this issue on high memory usage. It happens only when I've had multiple execution in my android studio. So first to make sure, I uninstall the app then run android studio. The app will install and all is good. Waited for a while checking the memory profiler but got nothing. All is good. Memory usage was great. No reports on leak in LeakCanary and no garbage collection is called often. Then after a while of repeated running the app in android studio because I am developing it currently, I notice the app would crash after 2 min mark. I check the memory profiler and I was right, the memory usage skyrocketed on 1-2 min mark. I have no idea why this is. I check the heap dump and no leaks reported. Even Leak Canary reported 0 leaks. I was just doing some UI fixes thats it. To make sure it was not happening on my main activity, I created a fake activity with just four buttons and still the memory usage will skyrocket on 1-2 min. This has been a problem when I started using dagger 2. According to some article, using a custom scope can be expensive so I don't use any scope. My app is not complicated and I don't have any asynctask and I am not yet using any coroutine atm. Here are the images I got.
Leak canary does not show anything leaks so Im quite baffled. I don't have any images on the activity as well. I implemented my dagger component on application level. My database is realm database, faster compared to room but I was not using it on my activity atm. Anyone had this issue like mine? Just wanted to know did you figure it out?
Thanks to Mark Keen's comment. Found the reason. It was the sentry.io calling okhttp. I remove it and the memory usage becomes stable.
Its an old post, but still in most of the places i found out that an android app gets around 16-32 MB memory
But when i check android Profiler, it says that my app is currently using around 350 MB memory on Samsung Galaxy S7.
I get OutOfMemoryException on my app a couple of times, I was curious why its happening. When i dig down a little i found out about 16-32 MB limit, but in actual my app is using 350 MB
I want to know how much memory a normal android phone gives to each app, or is it a variable number, and if no app is running android will not give outOfMemoryException, and if so many apps are in stack then there is a higher chance of OutOfMemoryException
But again there will be some limits.
Android devices vary significantly now that the OS is getting older. You should definitely aim for under 32mb limit if you want your app to work on lower end devices to be safe. Unless you are loading some very large images it sounds like your code is leaking memory.
Start by removing any image (or other asset) loading from your app to see if you still have problems.
If you do, check out LeakCanary, and when you find the leaks learn about them and why they are happening because it will help you immeasurably to become a better Android programmer. One of the chief ways apps leak memory is by passing an Activity context to a long running task :)
I'm developing a large project with android technology
sometimes I have some exceptions like (Out Of Memory Error) on small devices
what I do when an exception occurred is to re-open the application
what happen that it leaves the previous process open and open a new process with new instance of application
I have tried to make
finish()
kill process
System.exit
to close the application and re-open it again but nothing works for me
any help please ???
First Thing you have to take care of, is Heap size.. You can track How much memory is getting consumed when your are running application. Under DDMS perspective there is a heap tab which will give you info about how much memory is consumed when you are running your application.
on what version of the android you are testing ? Android Os will allocate some memory for each application to run.In android 2.2 16mb will be allocated for one application. Version 2.3 allocates 24Mb for an application ,Android 3.0 allocates 42Mb. try testing on different versions of android, you will get to know..
Out of memory happens when RAM in a device is utilized fully, the system will throw this error and kill/restart the process. You need to find the appropriate place where you use the most of memory and handle the memory properly. Out of Memory generally happens because of poor bitmap/image handling. Check your code where you handle Bitmaps/ImageViews/PNG's etc.
Android default heap size is almost good for every heavy load jobs. Trace your code and find memory consuming parts of your code and try to optimize them. To do so, use HEAP tab in DDMS view in Eclipse.
yes that is the problem .i have faced similar problem recently then i resized my images then my problem is solved.Try to find out a way how to reduce the size of the images which you are loading from sever side back-end.
I have a strange memory behavior in an Android application I'm developing. The application is running fine, but if I look to a "task manager" in Android, like the Samsung SII task manager or the "Memory Usage" application on a Nexus 7 it shows that while using the app the amount of memory used is rapidly growing to an insane amount, like hundreds of megas (600~700MB on the Nexus 7). Then it can fall down back to about 200MB, grow again etc.
At first I thought that I had a bad memory leak and started to search for the problem in the Eclipse Memory Analyzer (MAT) like it is explained in this excellent video. But the problem is that from here everything looks ok. I didn't find any duplicate instance of an activity or anything else that could cause the leak, and the reported amount of memory used is a lot smaller. The problem also doesn't appear in the GC messages. So I can have a 600MB use reported in the Task manager, and something like this in Logcat:
01-29 12:05:44.511: D/dalvikvm(6044): GC_FOR_ALLOC freed 3930K, 24% free 28959K/38096K, paused 17ms, total 17ms
with a heap amount never going above 50~60MB (which could be normal because there are lots of pictures in the app). Numbers in MAT match.
I would like to bu sure that there is a memory leak or not in my application. Even if GC messages and MAT don't report problems, I find it really strange that the task managers report such a high memory usage. Maybe someone here already faced such a strange behavior and could give me a clue about what is happening?
The GC messages only show what's on the Dalvik heap. The native heap can grow without bound -- until the system decides to kill you, which it is reluctant to do so long as you're in the foreground. Does your app have a native component that could be causing the allocations?
If this is a developer / rooted device, the "procrank" tool can give you a quick summary of memory usage. The "showmap " tool can give you a more detailed breakdown.
DDMS has some (officially unsupported) tools for examining native memory usage. Google for "ddms native heap" to find some instructions.
Ok, after hours of testing I've finally found the problem. As guessed by fadden, the leak was out of the Dalvik's scope. It was in fact due to the following bug in Typeface.createFromAsset:
http://code.google.com/p/android/issues/detail?id=9904
This method is leaking asset stream. My app is using a custom TextView to display text with custom fonts, and as it is used in most of the layout files it was rapidly leaking a lot of RAM, but not in Dalvik's heap, so it was really difficult to spot using the usual tools.
I am getting OutOfMemory Exception while running my project on both emulator and device(acer tablet and samsung galaxy) showing
the application launcher process com.android.launcher has stopped unexpectedly.
I've increase the virtual machine size of emulator to 256mb still there was no change in that exception. How can I avoid this exception? And how can I increase the process size of the heap for both emulator and device?
Please refer to this question
I don't know what kind of application you are running, but it's possible that you have a memory leak in your application. Then it would not matter how big you set your virtual machine size.
Check out the video below on how to find memory leaks in your own application. Works on devices and emulators. (I found a very big memory leak last week, that I didn't know I had in the application)
http://www.youtube.com/watch?v=_CruQY55HOk&feature=player_embedded
Unless you're doing something extreme and actually need lots of memory, you shouldn't have to resort to increasing the memory footprint. The bug that's causing this will probably run over any additional memory you give it.
Take a closer look at what comes before the out-of-memory error. I recently saw that one because I caused an endless configuration change loop. The only thing that stopped that endless loop was running out of memory.
While the few lines above the error looked fine, I realized that the number of log entries was much higher than normal, because it ran through the initialization for my activity repeatedly.
Your issue may be different, but I'm fairly sure that increasing the heap size won't fix it.