I just started using the Eclipse Memory Analyzer to try to solve a memory leak in my activity that extends MapActivity, but I am not sure if I understand its output correctly. In order to analyze the leak I started the activity and rotate the screen a couple of times and then I took a heap dump and opened it. The first thing I did was opening the Histogram view and look for my activity (called ChangeLocationActivity). This looks indeed like a memory leak, since there are three instances of the same Activity. So I got the list of objects with incoming references, then got the "Path to GC Roots" excluding weak references for all the three instances. This is the path of the first instance, this for the second instance (that custom MyLocationOverlay is a really simple class created to bypass a bug on some Motorola devices and it doesn't anything special apart from catching an Exception in drawMyLocation()) and finally this is the one for the third instance, which looks like the one currently shown.
As I said before I am not sure if I understand these results correctly (the Eclipse Memory Analyzer is really powerful but quite complex) but from what I can tell it looks like what's causing the memory leak is something related to the Google Maps library. Can anyone tell me if I am right or if I'm just not understanding these results?
Select all the activities and use "Merge Shortest Paths to GC Roots".
Post the result here.
Your second Activity seems to be alive because you registered an EventListener.
"Merge Shortest Paths to GC Roots" is one of the more important commands in MAT. It shows to all the pathes for objects to roots but merges them and therefore allows you to analyze which objects are still alive because they share the same pathes. From your screenshot (please expand the 3 subtrees) it seems your 3 activties are hold be 3 root objects. It is typical for leaks that the share some common objects along their merged root paths. Typically from what I've seen in your case you have more than one reason for the leak, because each activity is hold by a different root object. I would recommend to try to get as many activities to be leaked as possible by repeating the test.
Regards,
Markus
Related
I already dumped tons of memory and figured out that there certainly are memory leaks. If you look at the screenshot, you will see that there is just one fragment, but 9 presenters of the same type. There should be only one. When I inspect one of the presenter instances, the profiler shows me the references to the presenter.
Those are all callback methods of RxAndroid methods. I am unsubscribing properly all of those in onDestroyView of the Fragment. Still the presenter instances are not cleaned up (as you can see).
So I am wondering how to distinguish valid (circular, internal) references, which just still exists because the object is still not garbage collected, and problematic references (which are causing the object not to be cleaned up).
Can somebody guide me on how to figure out where the memory leak might be found?
This dump was generated AFTER triggering the GC!
You should try Leakcanary an open source library from Square to detect memory leaks. It saves you from doing lots of manual work like
Taking hprof dump
Analyse hprof dump to identify the leaks
Find reference which causes leak
Fix and repeat above steps
I have a blog of mine on memory leaks & Leakcanary, you can find it here
If you force a garbage collection using the memory profiler then you know the additional unexpected objects you see there are in use so it's possible they are real leaks and are not just waiting to be collected.
You need to find the path to gc root, this will tell you the object which is keeping the others from being garbage collected.
Check out the 'Garbge Collection Roots' section here for more info.
The Android memory profiler will tell you the shortest number of hops to get to the gc root but it may be better to just capture a hprof and use something like Eclipse MAT to see the path to gc root. Eclipse MAT can even check for leaks for you.
I am trying to understand how to identify and solve memory leaks.
I know how to deal with general memory leak issues. Leaked activities, inner classes etc. They are usually quite easy to identify. By dumping the heap and look for references.
Right now i am stuck with something probably very simple. Some very small object are stuck in the heap and i just cannot find any references to it in the heap explorer. See image below.
As you can see there is a MatchOddsAdapterStickyHeader instance and an array containing these instances.
My question is why these objects are still in the heap.?
The MatchOddsAdapterStickyHeader[] instance only contains references to a single MatchOddsAdapterStickyHeader instance. And each single MatchOddsAdapterStickyHeader only have a string. I just don't understand why GC did not clean up this objects. Both object have no references to any alive object. And yes i forced GC. makes no difference.
I know its only a few bytes. And it doesn't really give a problem in my app, but still i want to have a 100% memory leak free app if possible.
I experienced an OutOfMemory on my app and after some memory analyzing I got the following dominator tree. The first 4 instances are Activities that I started and directly closed. Since they hold a lot of views, the amount of memory that isn't garbage collected is huge.
If I then look into the path to GC for one of these elements I get the following:
The problem is that I don't know where these two references are coming from. I stripped the whole Activity to just have an onCreate/onDestroy, but I'm still getting these references. Does anybody know how to get rid of it so that the Activities can be garbage collected? Or is it a normal Android behavior and they will just disappear over time (which I doubt because I got the OutOfMemory)?
Thanks in advance for your help!
I ran MAT on my application to see if I can reduce memory leaks and `OutOfMemoryException's that are happening to my users.
I saw in the histogram that was generated by the tool that one of my activities wasn't cleared from memory even though I called finish and created no cyclic references that I was aware of. so I looked through all the incoming references excluding all soft/weak references and saw that there's an EditText that has no name and that I haven't put in the activity.
attached is a screenshot of the report.
please help me understand how to plug this leak.
I'm currently working on an android app with several activities. Most of the time, the app works fine, but from time to time an Out of Memory Exception occurs. (usually when trying to load the large background image for the next activity)
I couldn't find any obvious memory leaks, so I created a heap dump when the exception occurred (like described here) and tried to analyse it with MAT.
I haven't done something like this before, so I wasn't sure what exactly I should be looking for. I started clicking through the larger byte objects and the second one seems to be a Bitmap belonging to an ImageButton:
The Path to GC roots shows me an com.android.internal.policy.impl.PhoneWindow instance:
The thing is, the only ImageButton in my whole application is in my launch activity and between that launch activity and the crashing activity are at least 2 more activities.
So why is this image still in the heap??
The ImageButton is simply defined in the layout xml file using the android:src attribute, nothing is done via Code there. There are also a lot of other smaller objects from earlier activities in the heap.
I also wrote a little HelloWorld application and took a look in the heap dump of it and it seems, that android keeps the objects of previous activities in the heap. If this is the case, then an Out of Memory Exception has to be thrown some day, so I guess something must be wrong on my analysis :/
You might want to look at Bitmap managing in the developer's documentation.
In particular: a bitmap is kept in memory as long as a reference exists to it. So, if you absolutely have to use large bitmaps for your buttons (as you are describing) you might be do better by loading it manually and using recycle as soon as your Activity disappears from sight.
Okay, I just found this and realized, that stopped activities (and their objects) are NOT destroyed as long they are on the back stack. Even not if the active one needs more memory.
With this knowledge it is obvious why these objects like that ImageButton are still in the heap.
I still have to figure out the best way to release these resources, but I guess this strongly depends on the application itself and is hard to answer in general.