fd泄漏检测

一.摘要

我们在分析fd泄漏问题的时候一般的通用方法是在/proc/pid/fd下不断的ls -al | wc -l统计fd数量，并且查看哪个fd不断的增多，然后再去代码中排查对应的代码，有时候光看fd并不容易找到泄漏的地方。本文章将介绍高通的leakdetect方法。

 

二.leakdetect使用介绍

默认情况下手机已经包含了fd泄漏的检测代码，具体路径在：bionic/libc/malloc_debug/，它可以监控：file(1)，socket(2)，mmap(3)

具体原理就不多说了，有兴趣的自己看源码吧，下边介绍使用方法：

1.adb root 

2.adb shell setprop libc.debug.leakdetect 1（1代表监控file，2代表监控socket，3代表监控mmap）

3.adb shell setprop libc.debug.leakdetect.program app_process（安卓进程填app_process，native进程填对应的进程名字）

4.adb shell stop 

5.adb shell start

6.adb shell kill -28 pid(你要监控的进程)

7.当你的fd不断增加的时候再次输入:adb shell kill -28 pid

你会在logcat中看到对应的结果：O机器关键字：fd_leak_debug Q机器关键字：malloc_debug

 

三.结果展示

file泄漏检测结果：

06-02 11:59:34.040  5534 17218 E fd_leak_debug: Leak Type: file, count = 1, fd = 173, path = anon_inode:dmabuf

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #00  pc 0000000000004bd8  /system/lib64/libc_leak_detector.so (dup+124)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #01  pc 00000000000070f0  /system/lib64/libcutils.so (native_handle_clone+144)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #02  pc 0000000000005e84  /vendor/lib64/hw/android.hardware.graphics.mapper@2.0-impl.so (android::hardware::graphics::mapper::V2_0::implementation::GrallocMapper::importBuffer(android::hardware::hidl_handle const&, std::__1::function<void (android::hardware::graphics::mapper::V2_0::Error, void*)>)+80)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #03  pc 000000000001896c  /system/lib64/android.hardware.graphics.mapper@2.0.so

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #04  pc 0000000000014600  /system/lib64/libui.so (android::Gralloc2::Mapper::importBuffer(android::hardware::hidl_handle const&, native_handle const**) const+88)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #05  pc 0000000000017dc4  /system/lib64/libui.so (android::GraphicBufferMapper::importBuffer(native_handle const*, native_handle const**)+108)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #06  pc 0000000000016a04  /system/lib64/libui.so (android::GraphicBuffer::unflatten(void const*&, unsigned long&, int const*&, unsigned long&)+604)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #07  pc 00000000001373c8  /system/lib64/libandroid_runtime.so

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #08  pc 000000000006b9a4  /system/lib64/libbinder.so (android::Parcel::read(android::Parcel::FlattenableHelperInterface&) const+464)

06-02 11:59:34.040  5534 17218 E fd_leak_debug:           #09  pc 0000000000136e1c  /system/lib64/libandroid_runtime.so

mmap泄漏检测结果：

06-01 20:47:01.342 17087 19660 E malloc_debug: Leak Type: mmap, count = 1, addr = 0x794fee8000

06-01 20:47:01.342 17087 19660 E malloc_debug:           #00  pc 000000000000084c  /system/lib64/libc_leak_detector.so (mmap+180)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #01  pc 0000000000007bcc  /apex/com.android.runtime/lib64/libartbase.so (art::MemMap::MapInternal(void*, unsigned long, int, int, int, long, bool)+88)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #02  pc 0000000000007844  /apex/com.android.runtime/lib64/libartbase.so (art::MemMap::MapAnonymous(char const*, unsigned char*, unsigned long, int, bool, bool, art::MemMap*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, bool)+280)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #03  pc 000000000017aa84  /apex/com.android.runtime/lib64/libart.so (art::IndirectReferenceTable::IndirectReferenceTable(unsigned long, art::IndirectRefKind, art::IndirectReferenceTable::ResizableCapacity, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*)+176)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #04  pc 0000000000258890  /apex/com.android.runtime/lib64/libart.so (art::JNIEnvExt::JNIEnvExt(art::Thread*, art::JavaVMExt*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*)+52)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #05  pc 00000000002587fc  /apex/com.android.runtime/lib64/libart.so (art::JNIEnvExt::Create(art::Thread*, art::JavaVMExt*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*)+52)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #06  pc 00000000003ce91c  /apex/com.android.runtime/lib64/libart.so (art::Thread::CreateNativeThread(_JNIEnv*, _jobject*, unsigned long, bool)+400)

06-01 20:47:01.342 17087 19660 E malloc_debug:           #07  pc 0000000000308f28  /apex/com.android.runtime/lib64/libart.so

06-01 20:47:01.342 17087 19660 E malloc_debug:           #08  pc 0000000000007fec  /system/framework/arm64/boot.oat

06-01 20:47:01.342 17087 19660 E malloc_debug:           #09  pc 00000000003dcbf5  /apex/com.android.runtime/javalib/core-oj.jar

四.hprof辅助分析

    我们有了调用栈后还可以看下是哪个对象持有了这个fd，那么我们就需要抓一个hprof辅助分析，抓取方法：adb shell am dumpheap com.android.settings /data/local/tmp/settings.hprof，然后将settings.hprof pull到电脑上并打开，我们这里以“file泄漏检测结果”中的“file泄漏检测结果“来举例，之前我们已经看到了是和GraphicBuffer相关，那么我们在hprof中找到GraphicBuffer，我们发现它的引用关系是：ActivityManager->TaskSnapshot->mSnapshot

继续搜索：TaskSnapshot

我们发现这里创建了很多TaskSnapshot，因为TaskSnapshot中又包含了一个GraphicBuffer，所以这个时候我们就去排查TaskSnapshot为什么被一直被创建并且没有被回收

五.总结

    有了调用栈之后我们再去分析那就简单了很多了，不需要翻遍源码到处找在哪里泄漏了，直接从调用栈出发查问题就好了