2. 程式人生 > >Android NDK 記憶體洩露檢測

Android NDK 記憶體洩露檢測

阿新 • • 發佈：2019-01-21

前言

最近寫C++程式碼，老是擔心程式碼存在記憶體洩露，膽戰心驚的，Andorid中Java層程式碼記憶體洩露可以藉助leakcanary進行檢測；找了一番，找到了PC上C++上的記憶體洩露檢測庫LeakTracer，於是再找了下，找到了Android上的移植版。

首先建立一個專案，在根目錄下建立thirdparty目錄，進入該目錄，clone相關庫程式碼

1git clone git@github.com:lizhangqu/LeakTracer.git

在專案src/main/cpp下建立CMakeLists.txt，內容如下

12345678910111213141516171819202122232425262728293031project(Test)cmake_minimum_required (VERSION 3.6)include_directories( ${PROJECT_SOURCE_DIR}/include/ ${PROJECT_SOURCE_DIR}/../../../../thirdparty/LeakTracer/libleaktracer/include/ )set(LEAKTRACER_SOURCES ${PROJECT_SOURCE_DIR}/../../../../thirdparty/LeakTracer/libleaktracer/src/AllocationHandlers.cpp #${PROJECT_SOURCE_DIR}
/../../../../thirdparty/LeakTracer/libleaktracer/src/LeakTracerC.c #檢測c程式碼時開啟此註釋，否則不要開啟 ${PROJECT_SOURCE_DIR}/../../../../thirdparty/LeakTracer/libleaktracer/src/MemoryTrace.cpp )add_library(leaktracer STATIC ${LEAKTRACER_SOURCES})set(TEST_FILES ${CMAKE_SOURCE_DIR}/native.cpp)add_library( test-jni SHARED ${TEST_FILES}
)target_link_libraries( test-jni leaktracer log)

建立src/main/cpp/include/native.h和src/main/cpp/native.cpp檔案

native.h

1234567891011121314151617181920212223242526272829303132333435363738//// Created by 李樟取 on 2017/6/4.//#ifndef TEST_H#define TEST_H#include "jni.h"#ifndef NELEM# define NELEM(x) ((int) (sizeof(x) / sizeof((x)[0])))#endif#ifndef CLASSNAME#define CLASSNAME "io/github/lizhangqu/test/Test"#endif#ifdef ANDROID#include <android/log.h>#define TAG "Test"#define ALOGE(fmt, ...) __android_log_print(ANDROID_LOG_ERROR, TAG, fmt, ##__VA_ARGS__)#define ALOGI(fmt, ...) __android_log_print(ANDROID_LOG_INFO, TAG, fmt, ##__VA_ARGS__)#define ALOGD(fmt, ...) __android_log_print(ANDROID_LOG_DEBUG, TAG, fmt, ##__VA_ARGS__)#define ALOGW(fmt, ...) __android_log_print(ANDROID_LOG_WARN, TAG, fmt, ##__VA_ARGS__)#else#define ALOGE printf#define ALOGI printf#define ALOGD printf#define ALOGW printf#endif#endif //TEST_H

native.cpp

1234567891011121314151617181920212223242526272829303132333435363738394041#include "native.h"#include "MemoryTrace.hpp"#include <fstream>void test(JNIEnv *env, jobject thiz) {}static const JNINativeMethod sMethods[] = { { const_cast<char *>("test"), const_cast<char *>("()V"), reinterpret_cast<void *>(test) },};int registerNativeMethods(JNIEnv *env, const char *className, const JNINativeMethod *methods, const int numMethods) { jclass clazz = env->FindClass(className); if (!clazz) { ALOGE("Native registration unable to find class '%s'\n", className); return JNI_FALSE; } if (env->RegisterNatives(clazz, methods, numMethods) != 0) { ALOGE("RegisterNatives failed for '%s'\n", className); env->DeleteLocalRef(clazz); return JNI_FALSE; } env->DeleteLocalRef(clazz); return JNI_TRUE;}jint JNI_OnLoad(JavaVM *vm, void *reserved) { JNIEnv *env; if (vm->GetEnv(reinterpret_cast<void **>(&env), JNI_VERSION_1_6) != JNI_OK) { return -1; } registerNativeMethods(env, CLASSNAME, sMethods, NELEM(sMethods)); return JNI_VERSION_1_6;}

編寫test函式，簡單進行內測洩露檢測

1234567891011121314151617class MemoryTest {};void test(JNIEnv *env, jobject thiz) { leaktracer::MemoryTrace::GetInstance().startMonitoringAllThreads(); MemoryTest *memoryTest = new MemoryTest; leaktracer::MemoryTrace::GetInstance().stopAllMonitoring(); std::ofstream out; out.open("/sdcard/leaks.out", std::ios_base::out); if (out.is_open()) { leaktracer::MemoryTrace::GetInstance().writeLeaks(out); } else { ALOGE("Failed to write to \"leaks.out\"\n"); }}

執行程式後呼叫test函式，將/sdcard/leaks.out pull到專案根目錄

1adb pull /sdcard/leaks.out

其內容類似如下內容

12# LeakTracer report diff_utc_mono=1496511718.682943leak, time=135120.534718, stack=0x36fd6 0x35a90 0x359a4 0x32fea 0xc952d3d0, size=1, data=�

藉助thirdparty/LeakTracer/helper/leak-analyze-addr2line工具還原內測洩露堆疊。

進入專案根目錄，執行leak-analyze-addr2line

1./thirdparty/LeakTracer/helpers/leak-analyze-addr2line ./library/build/intermediates/cmake/debug/obj/armeabi/libtest-jni.so ./leaks.out

在mac上，會出現一個錯誤，原因是leak-analyze-addr2line中用到了addr2line工具，而mac上如果沒有此工具，就會報錯，錯誤如下：

error.png

解決方法很簡單，將ndk目錄中的arm-linux-androideabi-addr2line拷到./thirdparty/LeakTracer/helpers/下，並重命名為addr2line，然後將./thirdparty/LeakTracer/helpers/加到環境變數中，如下程式碼

12cp $ANDROID_NDK_HOME/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line ./thirdparty/LeakTracer/helpers/addr2lineexport PATH=$PATH:`pwd`/thirdparty/LeakTracer/helpers

$ANDROID_NDK_HOME表示ndk的根目錄。

之後再次呼叫命令

1./thirdparty/LeakTracer/helpers/leak-analyze-addr2line ./library/build/intermediates/cmake/debug/obj/armeabi/libtest-jni.so ./leaks.out

這時候輸出如下

out_leak.png

native.cpp:15行出現洩露，找到15行對應的程式碼，即如下程式碼出現洩露

1MemoryTest *memoryTest = new MemoryTest;

加入delete程式碼，再跑一次

12MemoryTest *memoryTest = new MemoryTest;delete memoryTest;

輸出如下

out_no_leak.png

發現之前的洩露不見了

最後，值得注意的是，要想使用LeakTracer需要保留so足夠多的debug資訊，否則可能不能正常檢測。

相關推薦

Android NDK 記憶體洩露檢測

前言最近寫C++程式碼，老是擔心程式碼存在記憶體洩露，膽戰心驚的，Andorid中Java層程式碼記憶體洩露可以藉助leakcanary進行檢測；找了一番，找到了PC上C++上的記憶體洩露檢測庫LeakTracer，於是再找了下，找到了Android上的移植版。首先建立一個專案，在根目錄下建立thirdpar

Android Native記憶體洩露檢測(針對Android7.0)

1. 需要合入一個 Patch 2. 執行指令 adb root adb shell setprop libc.debug.malloc.program cameraserver adb shell setprop libc.debug.malloc.options “backt

Android native memory leak detect (Android native記憶體洩露檢測)

簡介 Android應用中，經常會有業務需要使用到Native實現。比如加密，音視訊播放等。也就是常見的二進位制檔案xxx.so 這部分程式碼，申請的記憶體不走Java Heap管理。那麼一旦發生記憶體洩露，無法使用匯出MAT來進行檢視。 本篇文章將講解如

Android記憶體洩露檢測工具和實際開發中遇到的記憶體洩露問題解析

介紹 記憶體洩露是平常開發中經常遇到的，有些時候稍不注意就會發生，而且還不易察覺，這就需要工具來幫助檢測。本文主要介紹記憶體檢測工具和我在開發中遇到的記憶體洩露問題和解決方案。 記憶體洩露的原理 具體的原理涉及到虛擬機器垃圾回收機制知識，這裡只為下文作

Linux核心的Kmemleak實現記憶體洩露檢測

1. Kmemleak的使用方法     a. 在uboot的bootarg中加入"kmemleak=on"     b. 在.config中使能如下配置 CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_

linux下記憶體洩露檢測工具Valgrind介紹

一、工作中一個記憶體洩漏問題的解決過程： 問題背景：我司裝置上執行有多個程序，在裝置執行兩天後，程序jsman所佔用的記憶體達到了1200M bytes（通過ps -aux檢視）。 解決步驟： 確定裝置上的軟體版本，根據git的commit號資訊回退

DevPartner Studio Professional Edition 11 記憶體洩露檢測使用

                     DevPartner Studio Professional Edition含有靜態程式碼分析、錯誤檢測、效能、覆蓋率和記憶體分析以及效能專家功能，用於 Visual Studio 2012、Visual Studio 2010、Visual Studio 2008

精準 iOS 記憶體洩露檢測工具----MLeaksFinder

背景 平常我們都會用 Instrument 的 Leaks / Allocations 或其他一些開源庫進行記憶體洩露的排查，但它們都存在各種問題和不便，我們逐個來看這些工具的使用和存在的問題。 Leaks 先看看 Leaks，從蘋果的開發者文件裡可以看到，一個 app 的記憶體分三類：

c++記憶體洩露檢測

// 以下程式碼在vs2013上面測試#include <stdlib.h> #include <crtdbg.h> // 在入口函式中包含 _CrtDumpMemoryLeaks(); // 即可檢測到記憶體洩露 typedef void* HObjec

Android studio記憶體洩露分析工具使用

什麼是記憶體洩漏 Android虛擬機器的垃圾回收採用的是根搜尋演算法。GC會從根節點（GC Roots）開始對heap進行遍歷。到最後，部分沒有直接或者間接引用到GC Roots的就是需要回收的垃圾，會被GC回收掉。而記憶體洩漏出現的原因就是存在了無

利用Android Studio、MAT對Android進行記憶體洩漏檢測

專案進入維護階段時才有時間測試分析app的記憶體問題,這時就要用到測試工具了,可以使用Android Studio、MAT互相結合進行測試, 但是對於複雜的,這兩者很難分析出來,但這兩測試工具也是必須掌握的,感覺網上大多文章講得不怎麼細緻,所以想寫篇文章記錄下,剛好看到本文

Linux下利用Valgrind工具進行記憶體洩露檢測和效能分析

Valgrind通常用來成分析程式效能及程式中的記憶體洩露錯誤 一 Valgrind工具集簡紹 Valgrind包含下列工具：     1、memcheck：檢查程式中的記憶體問題，如洩漏、越界、非法指標等。     2、callgrind：檢測程式程式碼的執行

循序漸進學用MAT排查Android Activity記憶體洩露

一、先磨刀再砍柴，記憶體洩露相關介紹   我們先來簡單重溫一下Java GC 的概念：GC即為Garbage Collection，垃圾回收機制。Java GC實質上也就是一個執行在Java虛擬機器（JVM）上的一個程式，它自動地管理著記憶體的使用，在適當的時

Visual C++ 記憶體洩露檢測工具（VLD）

簡述 C/C++ 程式越複雜，記憶體的管理顯得越重要，稍有不慎就會出現洩漏。如果記憶體洩漏不是很嚴重，在短時間內對程式不會有太大影響，這也使得記憶體洩漏問題有很強的隱蔽性，不易被發現。然而不管記憶體洩漏多麼輕微，當程式長時間執行時，其破壞力是驚人的 - 從效能

使用Visual Leak Detector for Visual C++ 捕捉記憶體洩露---Visual C++記憶體洩露檢測—VLD工具使用說明

以下經過測試： 使用Visual Leak Detector for Visual C++ 捕捉記憶體洩露 1、下載vlc 2、建立應用並配置 c/c++ -> General -> Additional Include Directories = C:\P

Windows/Linux下C/C++記憶體洩露檢測工具

一 Window下的記憶體洩露檢測(以VC++環境為例） 靈活自由是C語言的一大特色，但這個特色也難以避免的帶來一些副作用，比如記憶體洩露。眾所周知，記憶體洩露的問題比較複雜，程式正常執行時你看不出它有任何異常，但長時間執行或在特定條件下特定操作重複多次時，它才暴露出來。所

VS 2013記憶體洩露檢測的方法

例項： #include "stdafx.h" #ifdef _DEBUG #define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__) #else #define DEBUG_CLIENTBLOCK

Android應用記憶體洩露分析、改善經驗總結

前言   通過這幾天對好幾個應用的記憶體洩露檢測和改善，效果明顯： 完全退出應用時，手動觸發GC，從原來佔有記憶體100多M降到低於20M； 手動觸發GC後，通過adb shell dumpsys meminfo packagename -d檢視Activity和View的數量也趨近於0了（沒有做到歸零

iOS-記憶體洩露檢測工具(MLeaksFinder)

MLeaksFinder MLeaksFinder helps you find memory leaks in your iOS apps at develop time. It can automatically find leaks in UIVi

Linux C 程式設計記憶體洩露檢測工具(二)：memwatch

Memwatch簡介 在三種檢測工具當中，設定最簡單的算是memwatch，和dmalloc一樣，它能檢測未釋放的記憶體、同一段記憶體被釋放多次、位址存取錯誤及不當使用未分配之記憶體區域。請往http://www.linkdata.se/sourcecode.html下載最