BioWallet Blog

Note: This procedure is valid for SDK versions up to 1.1. For instructions about how to do it in Android 1.5 take a look at our new post: Analyze an Android 1.5 memory dump.

In this post we will show you how to get a memory dump of your running Android application, convert it to a standard format supported by the conventional tools and open it with Eclipse MAT (Memory Analyzer Tool) to detect memory leaks.

The memory dump is going to be generated on the /data/misc directory so the first step is modifying its permissions to make sure it is writable.

adb shell #su #chmod 777 /data/misc

Note: You can do this on the emulator or if you are working with an Android Developer Phone, but you cannot do it if you are working with a T-Mobile G1 (unless you are root, but that's for another post). The ‘su’ command is only needed if you are working with an ADP1 because the adb daemon runs as a regular user.

Next, we should run our application and take note of its process number. It can be found using the DDMS view in Eclipse




or if you are a command line guy you can use:

#ps

to list the currently running processes.


We will use this number to send a SIGUSR1 signal to the process. Currently the Dalvik VM will generate a memory dump in response to two signals, SIGQUIT and SIGUSR1.  If you send it a SIGQUIT it will dump the stacks from all running threads; if you send it a SIGUSR1 it will dump the heap profiling data. The most usual way to send the signal to the process is with the kill command:

kill -10 <pid number>

but you can also send it programmatically from inside the application with this code:

android.os.Process.sendSignal(android.os.Process.myPid(), android.os.Process.SIGNAL_USR1);

On a "regular" JVM you could generate a dump in the very moment the first OOM occurs (starting it with the -XX:+HeapDumpOnOutOfMemoryError option), which is very useful, but that feature is not available in Dalvik yet (however, it is on the “to do list” of the Android team).


If everything works OK, you should see something like this on the log:


04-28 13:53:32.418: INFO/dalvikvm(22609): threadid=7: reacting to signal 10
04-28 13:53:32.418: INFO/dalvikvm(22609): SIGUSR1 forcing GC and HPROF dump
04-28 13:53:32.418: INFO/dalvikvm(22609): hprof: dumping VM heap to "/data/misc/heap-dump-tm1240926812-pid22609.hprof".
04-28 13:53:35.682: INFO/dalvikvm(22609): hprof: dumping heap strings to "/data/misc/heap-dump-tm1240926812-pid22609.hprof-head".


Now we can pull the generated files to the computer:

adb pull /data/misc/heap-dump-tm1240926812-pid22609.hprof-head . adb pull /data/misc/heap-dump-tm1240926812-pid22609.hprof .

And we have to join them in a single file. If you are in a Windows system you could use the ‘type’ command:

C:\...>type heap-dump-tm1240926812-pid22609.hprof-head > android-dump.hprof C:\...>type heap-dump-tm1240926812-pid22609.hprof >> android-dump.hprof

or ‘cat’ in a Linux system.


The generated dump contains specific information related with the Dalvik VM that are not part of the standard hprof format so the standard tools won’t be able to open it. Luckily, the Android team has released a tool to trim the Dalvik specific records and convert the dump to a standard format. You can find the source code here. Also, if you are using windows you can download a compiled version from here (compiling it for other systems shouldn’t be difficult, ask us if you have any problem).

C:\...>hprof-conv android-dump.hprof standard-dump.hprof

Finally you can open it with your preferred analysis tool (JHat, JProfiler, MAT, etc.). In this post and followings we will be using MAT.





That’s all for now! We will publish more information soon about how to use MAT to detect and solve memory leaks in your application.