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.
Related
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 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
I am referencing this to memory profiling of my application, when I launched TraceView with my trace file, there are several colors and items shows on TraceView window.
So how can I understand where memory leaks, and what is means of colors.
I don't think you should use TraceView for memory leaks finding. It's a tool for getting information about performance and memory usage of applications. Try Memory Analyzer Plugin for Eclipse. You can make a dump of your app's memory with Dump HPROF file button in DDMS and look for memory leaks in this dump using MAT.
UPDATE:
When the memory dump is made you'll see MAT's Getting Started Wizard with Leak Suspects Report radio button checked. Click Finish button and you'll see Leak Suspects window. There will be a diagram of memory usage and a list of potential leaks. Some leaks are false-positive. If you think that a particular leak is the real one, you can click on a Detail link to get more information about this leak.
When the Detail tab opens you will see a path to a leaked object. You can click any objects in the path and get some useful information about these objects. For example you can get a list of objects that have a reference to the selected object (List objects -> with outgoing reference).