Android Native Memory allocations and leaks

Prerequisites

   Built Android platform code base, SDK and NDK.

Emulator setup

/out/host/darwin-x86/bin/emulator -system   /out/target/product/generic/system.img -ramdisk out/target/product/generic/ramdisk.img

adb shell setprop libc.debug.malloc 1
adb shell stop
adb shell start

       1  - perform leak detection
       5  - fill allocated memory to detect overruns
     10 - fill memory and add sentinels to detect overruns
     20 - use special instrumented malloc/free routines for the emulator

Host setup

vi ~/.android/ddms.cfg
add a line "native=true"

export ANDROID_SYMBOLS=/out/target/product/generic/symbols
export PATH=$PATH:/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/

DDMS

/tools/ddms

Select the process in ddms and click on Native Heap tab and select "Snapshot Current Native Heap Usage".

Comments

JD said…
This comment has been removed by the author.
April 7, 2014 at 2:12 AM
JD said…
How did you get this path -
export PATH=$PATH:/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/

?
April 7, 2014 at 2:14 AM
JD said…
I am using android 4.3 and i dont see the path exists :/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/
April 7, 2014 at 2:15 AM
Anonymous said…
Toolchains is from Android NDK Installation.
April 30, 2014 at 8:43 PM
Post a Comment

Popular posts from this blog

Android Shared User ID and android:process

      Android's shared user id (android:sharedUserId) is a way for different applications to share the same user id for permissions, which lets them access their data and host their components in other process space. By declaring a new sharedUserId in the manifest, a new user id is creating during installation and is ready to be used by other applications provided they are signed with the same certificate and one such use is to update android:process of an application component to host it in other process space.    However, if the applications don't share a user id and aren't signed with the same certificate, a new process is launched with the same name as in android:process and this new process automatically shares userId with the requested application.    If the applications share user id and and aren't signed by the same certificate, the installation of the apk would fail.     If the applications share user id and are signed by the ...
Read more

Android's Watchdog daemon

    Android framework's Watchdog (Java implementation) is meant to handle cases when the framework ends up in an unresponsive state. However, this doesn't help handle kernel or other OEM specific driver issues. Chip vendors usually provide a hardware watchdog to hard reset the system to handle software failures. The hardware watchdog just waits to be reset by software within a specific duration and force resets the system if otherwise. The hardware watchdog is just handled by a vendor specific watchdog driver and it exposes IOCTL APIs for user space to set timeout interval, reset the watchdog etc. So does Android provide any support?     Its supported by a daemon process (/sbin/watchdogd) and OEMs could use this to fine tune timeout intervals or even completely disable it. watchdogd is really a symbolic link to init process.     lrwxrwxrwx root     root              1969-12-31 19:00 watchdogd -> ../init ...
Read more

Android : Watchdog is killing system server

Here goes my first fix in Android. Watchdog of the android framework is implemented to make sure the framework is rebooted in case of non-recoverable errors like deadlocks etc. Usually, i have seen frameworks where in the entire phone is rebooted upon such errors. Android is smart in the sense that its efficient by offering the framework reboot within seconds [Technically, it is just spawning of a linux process, system_server]. Monkey is a tool available to feed in random key events for stress testing and we happened to see a lot of scenarios where in the watchdog would kill the system server, causing android framework reboot. It seemed as if the root cause was within the framework and moreover it was random key events passed to the framework over many hours. The pattern to reproduce was not known but yet happened quite often. Like all bugs, it turned out to be 100% reproducible just that it took time to figure out the pattern. Monkey has an activitycontroller to report ANRs an...
Read more