I’ve been trying to diagnose a memory leak in an Android application I’m writing. I got a heap dump loaded into Eclipse, but the results I’m seeing are very curious. There are some 20,000 instances of an exception (specifically, LDAPException from the UnboundID LDAP library) in the heap with no inbound references.
That is, they show up at the root of the dominator tree. The OQL SELECT objects e FROM com.unboundid.ldap.sdk.LDAPException e WHERE (inbounds(e).length = 0) returns over 20,000 results, totalling to nearly all of the heap. And yet, the GC runs before the heap dump and I can see that it’s running in the console, repeatedly, during the execution of the leaky code. If these instances have no inbound refs, what could be keeping them alive?
I also tried doing a “shortest paths to GC” query. It shows one LDAPConnectionReader row retaining 2 instances, and ~20k LDAPException @ <addr> unknown rows with various hex addresses.
Update: I haven’t had time to further diagnose this since posting it, and the bounty I posted is ending before I likely will. I’m awarding it as best I can now, lest the points go to waste. Thanks to everyone who looked into this! I will come back later and update again with the results of further diagnosis, when life is a little less hectic.
Whether or not these Exceptions are being thrown, in terms of memory usage, that detail is pretty much irrelevant.
While you’d like to see in the heap dump who holds the references, for some reason, you’re not able to get to this. I wonder if native code would get symbolized properly in the heap dump tool?
Either way, as something new to try, I’d suggest not debugging the point at which these Exceptions are thrown but where they are created. Put breakpoints on the class and/or all of its constructors. Ideally, you’d just get this information from the heap dump references, but it still may prove to be informative if you can see who is repeatedly constructing these objects… I’m guessing they come from the same place.