Nota: Este post está pendiente de traducción.
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 this 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.
1
2
3
|
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 this 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:
but you can also send it programmatically from inside the application with this code:
1
|
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:
1
2
|
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 (or ‘cat’ in a Linux system.):
1
2
|
C:\...>type heap-dump-tm1240926812-pid22609.hprof-head > android-dump.hprof
C:\...>type heap-dump-tm1240926812-pid22609.hprof >> android-dump.hprof
|
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.
1
|
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.
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.
1
2
3
|
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 this 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:
but you can also send it programmatically from inside the application with this code:
1
|
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:
1
2
|
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 (or ‘cat’ in a Linux system.):
1
2
|
C:\...>type heap-dump-tm1240926812-pid22609.hprof-head > android-dump.hprof
C:\...>type heap-dump-tm1240926812-pid22609.hprof >> android-dump.hprof
|
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.
1
|
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.
Mobbeel se enorgullece de participar junto con el Ayuntamiento de Cáceres en el proyecto de seguridad biométrica para el Garaje 2.0. Por otra parte, agradecemos la apuesta decidida por la Innovación y el Desarrollo por parte del Ayuntamiento de Cáceres como camino a seguir.
