How To Find That Memory Leak (Part Three): Why An Object is Leaking Into Memory

How-to

This is the third of a three-part series on how to detect a memory leak. In part one, I explained the most common cases for a memory leak in a Java® development environment, and how that can affect your application. In part two, I discussed how to detect potential leaks. Today, we’re going to investigate why an object is leaking into memory in the first place.

Leak investigation

Once you’ve identified the class name of the object that is leaking, open the object’s view – View/Objects. This view allows viewing all class instances currently on the BlackBerry® smartphone. Before proceeding, press the “GC” button to clean any unreferenced instances (you may have done this already in the Object Statistics view, but doing it again doesn’t hurt). Starting with the BlackBerry® Java® Development Environment (BlackBerry JDE) v4.6, you can take advantage of a convenient functionality that lets you show all recursive references to an instance. So if you’re using BlackBerry JDE 4.6 or newer, follow the set of instructions below; otherwise look at the second set of instructions.

  1. In the “Type:” field, enter the name of the class you’re after – e.g. “TestMemoryLeaks” – and press enter. You will get a list of instances – these are the actual “leaks”.
  2. Pick one of those instances in the objects view, right-click and choose “Show Recursive References”. This will yield a very large list of objects (everything that references your object, directly or indirectly).
  3. In the “Location” dropdown, select “Root Objects”. This will restrict the view to root references only (static variable, persistent root, app registry, local variables, etc).
  4. One of the instances in the list will be of a class called ApplicationRegistryHashtable. Right click on it and choose “Show paths from @xxxxxx to @yyyyy”.
  5. Now you have the reference chain that causes the leak.

If you have a version of the BlackBerry JDE older than 4.6, use the following steps:

  1. In the “Type:” field, enter the name of the class you’re after – e.g. “TestMemoryLeaks” – and press enter. You will get a list of instances – these are the actual “leaks”.
  2. Pick one of those instances in the objects view, right-click and choose “Show References to @xxxxxxx”. This will give you a list of immediate references.
  3. Check if one of the instances in the list is not ApplicationRegistryHashtable. If it is then go to step 6.
  4. Right-click on any item in the new list and select “Show References To This Object List”. This will give you another list.
  5. Repeat steps 3 and 4 until you reach an instance of ApplicationRegistryHashtable.
  6. Right-click on ApplicationRegistryHashtable and choose “Show paths from @xxxxxx to @yyyyy”.
  7. Now you have the reference chain that causes the leak.

Having the reference chain to the leaked object instance should provide you with enough information about what caused the problem, and to avoid it.

So enough reading, hunters – minimize this browser and go back to your BlackBerry JDE to start the memory leak hunt! After that, come back and share your experience with everyone by posting a comment. Have you found any leaks? What were the core reasons for having the leaks on the first place? Let us all know.

About Kamen V.

Kamen is a Senior Architect, Strategic Initiatives, and started at Research In Motion (RIM) in 2001 with already established expertise in development for the BlackBerry platform and other mobile devices. Since then Kamen has been part of both device and server-side design and development activities - helping to evolve the BlackBerry development environment. As part of the Strategic Initiatives group he is now involved in looking for new ways to bring additional value to third party developers.

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus