高通车机8155平台android开启ASAN定位内存问题方法

已于 2024-06-14 14:39:45 修改
阅读量945 收藏 3
点赞数 1
文章标签： android linux
于 2023-10-09 19:38:53 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/suixin______/article/details/133713263
版权

前言

高通8155平台有自己的客制化，仅按照google的描述在编译命令里面加上-fsanitize=address是不能够编译出来带ASAN的bin或者SO。还需要更多的编译属性配置。

一、system分区模块打开ASAN

修改自己对应模块bin以及shared libs 的Android.bp 

1. 针对Android.bp情形

Android.bp 的cflags 里面添加 :

 "-Wno-error", "-fno-omit-frame-pointer", "-O0", "-Wno-frame-larger-than="

Android.bp 申明属性 :

clang: true  sanitize: {address: true,}

示例如下：

cc_defaults {
    name: "asan_debugd_defaults",
    cflags: [
        "-Werror",
        "-Wall",
        //enable asan related cflags begin
        "-Wno-error",
        "-fno-omit-frame-pointer",
        "-O0",
        "-Wno-frame-larger-than=",
        //enable asan related cflags end
    ],
     
    clang: true,  //ASAN related property
    sanitize: {address: true,}, //ASAN option
 
    cppflags: [
        "-Wnon-virtual-dtor",
        "-fno-strict-aliasing",
    ],
    ldflags: [
        "-Wl",
    ],
}
 
 
cc_binary {
    name: "asan_debugd",
    defaults: ["asan_debugd_defaults"],
    static_libs: [ "libAsanDebug",],
    shared_libs: [ "liblog", "libutils", "libcutils"],
    srcs: ["asan_debugd.cpp"],
}

注意，如果bin开启了ASAN，则bin的static libraries 都默认开启ASAN。而shared libraries 不会感染编译配置。所以可疑的shared libs 也要加。

2, 针对Android.mk情形

Android.mk需要打开如下属性：

LOCAL_CFLAGS += -fno-omit-frame-pointer -O0 -Wno-frame-larger-than= -fsanitize=address

LOCAL_CLANG := true

LOCAL_SHARED_LIBRARIES +=libclang_rt.asan-aarch64-android

其中LOCAL_SHARED_LIBRARIES 所申明的.so，在/system/lib64/里面有，在/system/lib/里面的so叫另外一个名字libclang_rt.asan-arm-android.so, 所以最好仅编译64位版本。只要能复现问题，不必32、64位都要编译。

示例（仅演示64位）如下：

LOCAL_PATH := $(call my-dir)
 
################################### /system/bin/asan_debugd ############################################
 
include $(CLEAR_VARS)
LOCAL_MODULE := asan_debugd
 
LOCAL_CFLAGS := -Werror
 
LOCAL_LDFLAGS += -Wl
 
LOCAL_CPPFLAGS += -Wfloat-equal -Wformat=2 -Wshadow -fstack-protector-all
 
LOCAL_MODULE_TAGS := optional
 
LOCAL_MULTILIB :=64
 
LOCAL_SRC_FILES += asan_debugd.cpp
 
LOCAL_C_INCLUDES := $(LOCAL_PATH)
 
LOCAL_SHARED_LIBRARIES := liblog libutils libcutils \
                          libAsanDebug
 
#LOCAL_STATIC_LIBRARIES :=  libAsanDebug
 
#asan related cflags
LOCAL_CFLAGS += -fno-omit-frame-pointer  -O0 -Wno-frame-larger-than=  -fsanitize=address
LOCAL_CLANG := true
LOCAL_SHARED_LIBRARIES +=libclang_rt.asan-aarch64-android
 
include $(BUILD_EXECUTABLE)

二，vendor分区打开ASAN

1, 预编译ASAN库

vendor空间所开启的编译命令与上述类似。但是有个问题，在/vendor/lib64/里面没有libclang_rt.asan-aarch64-android.so，所以需要把/system/lib64/里面的libclang_rt.asan-aarch64-android.so 预编译到/vendor/lib64.

如果不会写预编译的Android.mk 可以点击下面链接下载，预编译的lib以及Android.mk我都整理号了：

高通8155p平台QNX+Android9开启ASAN定位内存问题方法Android.mk与Android.bp都有_高通8155资源-CSDN文库

上述文件夹下载好了，放到能够编译到的地方即可。然后修改自己模块的Android.mk或者Android.bp 以下假设我预编译到vendor/lib(64)的.so改名叫做libclang_rt.asan-android_vnd.so

为了方便大家调试，我把32、64位的.so都编译进去了。并且各位的Android.bp不用再声明32或者64了。 

2，vendor分区Android.bp

cc_defaults {
    name: "asan_debuglib_defaults_vnd",
    cflags: [
        "-Werror",
        "-Wall",
        "-Wno-error",                 // asan related cflags
        "-fno-omit-frame-pointer",    // asan related cflags
        "-O0",                        //  asan related cflags
        "-Wno-frame-larger-than="     // asan related cflags
    ],
    cppflags: [
        "-Wnon-virtual-dtor",
        "-fno-strict-aliasing",
    ],
    ldflags: [
        "-Wl",
    ],

    shared_libs: [ "liblog", "libutils", "libcutils", 
        "libclang_rt.asan-android_vnd",
    ],
    clang: true, // asan related cflags
    sanitize: {address: true,}, // asan related cflags
    compile_multilib: "64",
}

// vendor/lib64/libAsanDebug_vnd

cc_library_shared {
    name: "libAsanDebug_vnd",
    vendor: true,  //vendor partition
    defaults: ["asan_debuglib_defaults_vnd"],
    static_libs: [
    ],
    export_include_dirs: ["export_headers", ],
    srcs: ["AsanDebug.cpp"],
}

3，vendor分区Android.mk

LOCAL_PATH := $(call my-dir)

##################################### /vendor/lib64/libAsanDebug_vnd #################################

include $(CLEAR_VARS)
LOCAL_MODULE := libAsanDebug_vnd

LOCAL_CFLAGS := -Werror

LOCAL_LDFLAGS += -Wl

LOCAL_MODULE_TAGS := optional

LOCAL_SRC_FILES +=  AsanDebug.cpp

LOCAL_C_INCLUDES := $(LOCAL_PATH) \
                    $(LOCAL_PATH)/export_headers


LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)/export_headers


#ifeq (1,$(filter 1,$(shell echo "$$(( $(PLATFORM_SDK_VERSION) >= 26 ))" )))
LOCAL_PROPRIETARY_MODULE := true
#endif

LOCAL_SHARED_LIBRARIES :=liblog libutils libcutils

#asan related configure begin
LOCAL_CFLAGS += -fno-omit-frame-pointer  -O0 -Wno-frame-larger-than=  -fsanitize=address
LOCAL_CLANG := true
LOCAL_SHARED_LIBRARIES +=libclang_rt.asan-android_vnd
#asan related configure end

include $(BUILD_SHARED_LIBRARY)
#include $(BUILD_STATIC_LIBRARY)

三、编译问题汇总

1，虚函数没有被子类实现

Base.h:0: error: undefined reference to 'vtable for 
prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: the vtable symbol may be undefined because the class is missing its key function
Base.h:0: error: undefined reference to 'vtable for 
prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: the vtable symbol may be undefined because the class is missing its key function
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
[ 68% 20/29] target Prebuilt:...D/vendor.gwm.hardware.health@1.0-service-client)
ninja: build stopped: subcommand failed.

解决办法： 

diff --git a/1.0/default/impl/src/monitor/MonitorBase.h b/1.0/default/impl/src/monitor/MonitorBase.h
index 2590edd..a1c31ad 100755
--- a/1.0/default/impl/src/monitor/MonitorBase.h
+++ b/1.0/default/impl/src/monitor/MonitorBase.h
@@ -50,7 +50,7 @@ class MonitorBase : public android::RefBase {
   MonitorBase() {}
   virtual ~MonitorBase() {}
 
-  virtual void dumpResource();
+  virtual void dumpResource() {}

2，surfaceflinger开启后也会出现如下问题：

frameworks/native/services/surfaceflinger/RenderEngine/RenderEngine.h:0: error: undefined reference to 'vtable for android::RE::RenderEngine'
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/arm-linux-androideabi/bin/ld: the vtable symbol may be undefined because the class is missing its key function
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

解决方法：

diff --git a/services/surfaceflinger/RenderEngine/RenderEngine.h b/services/surfaceflinger/RenderEngine/RenderEngine.h
old mode 100644
new mode 100755
index 178615548..2d15eabd1
--- a/services/surfaceflinger/RenderEngine/RenderEngine.h
+++ b/services/surfaceflinger/RenderEngine/RenderEngine.h
@@ -103,7 +103,7 @@ public:
     virtual void unbindNativeBufferAsFrameBuffer(RE::BindNativeBufferAsFramebuffer* bindHelper) = 0;
  
     // set-up
-    virtual void checkErrors() const;
+    virtual void checkErrors() const = 0;
     virtual void setViewportAndProjection(size_t vpw, size_t vph, Rect sourceCrop, size_t hwh,
                                           bool yswap, Transform::orientation_flags rotation) = 0;
     virtual void setupLayerBlending(bool premultipliedAlpha, bool opaque, bool disableTexture,

四，编译与运行

ASAN在发现有违规内存操作的时候，就会ABORT该进程，并产生tombstone，main log打印 异常栈。在如踩内存发生的时候就会打印，而不会等到被踩内存时候发生。

ASAN检测内存泄漏能力较弱。通常要等到应用推出时候才会把统计的未释放的内存打印出来。这就需要程序设计能够正常推出的代码流程。

以下烂代码为例，开启 ASAN：


+  if (HeartBeatCount > 60) {
+       char* p = (char*)malloc(40);
+       for(int x = 0; x < 50; x ++) {p[x] = 'c';}
+  }
+

编译、烧写，开机；抓取adb log.

运行ASAN时候，可以开启环境变量。具体就是修改对应进程的init.rc,加上setenv：

 service zygote /system/bin/app_process32 -Xzygote /system/bin --zygote --start-system-server --socket-name=zygote
     class main
+    setenv ASAN_OPTIONS halt_on_error=0:allow_user_segv_handler=true:abort_on_error=0:continue_on_error=2:allow_user_segv_handler=1
     priority -20
     user root
     group root readproc reserved_disk

注意，上述部分环境变量有的时候也需要同时在编译时候声明。我不确定哪些是需要编译时候声明的，所以，编译之前 export 一下环境变量：

export ASAN_OPTIONS=detect_leaks=1
export ASAN_OPTIONS=${ASAN_OPTIONS}:halt_on_error=1
make

五， LOG分析

上述在运行时候会产生如下LOG打印：

01-02 03:13:59.407   573   626 I HealthFdbusClient: sendHeartBeat: sendHeartBeat count=60
01-02 03:13:59.408   573   626 I vendor.gwm.hardware.health@1.0-service: =================================================================
01-02 03:13:59.408   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.409   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.409   573   626 I vendor.gwm.hardware.health@1.0-service: ==573==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x003200039678 at pc 0x005892d4c428 bp 0x007692802970 sp 0x007692802968
01-02 03:13:59.409   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.409   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.409   573   626 I vendor.gwm.hardware.health@1.0-service: WRITE of size 1 at 0x003200039678 thread T3
01-02 03:13:59.409   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service:     #0 0x5892d4c427  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x28427)
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service:     #1 0x5892d3bdd3  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x17dd3)
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service:     #2 0x5892d3e693  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x1a693)
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service:     #3 0x5892d43813  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x1f813)
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service:     #4 0x76968439b7  (/system/lib64/libc.so+0x819b7)
01-02 03:13:59.422   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service:     #5 0x76967e547b  (/system/lib64/libc.so+0x2347b)
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.423   573   626 I chatty  : uid=0(root) health@1.0-serv identical 1 line
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service: 0x003200039678 is located 0 bytes to the right of 40-byte region [0x003200039650,0x003200039678)
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service: allocated by thread T3 here:
01-02 03:13:59.423   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service:     #0 0x76957ac133  (/system/lib64/libclang_rt.asan-aarch64-android.so+0x9d133)
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service:     #1 0x5892d4c38b  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x2838b)
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service:     #2 0x5892d3bdd3  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x17dd3)
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service:     #3 0x5892d3e693  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x1a693)
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service:     #4 0x5892d43813  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x1f813)
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.424   573   626 I vendor.gwm.hardware.health@1.0-service:     #5 0x76968439b7  (/system/lib64/libc.so+0x819b7)
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service:     #6 0x76967e547b  (/system/lib64/libc.so+0x2347b)
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.425   573   626 I chatty  : uid=0(root) health@1.0-serv identical 1 line
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service: Thread T3 created by T0 here:
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service:     #0 0x76957999bf  (/system/lib64/libclang_rt.asan-aarch64-android.so+0x8a9bf)
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.425   573   626 I vendor.gwm.hardware.health@1.0-service:     #1 0x5892d3f8c7  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x1b8c7)
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service:     #2 0x5892d35953  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x11953)
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service:     #3 0x5892d3687b  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x1287b)
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service:     #4 0x5892d3172f  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0xd72f)
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service:     #5 0x769686eacb  (/system/lib64/libc.so+0xacacb)
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service:     #6 0x5892d315d7  (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0xd5d7)
01-02 03:13:59.426   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.429   573   626 I vendor.gwm.hardware.health@1.0-service:     #7 0x7696aaf58f  (/system/bin/linker64+0x2e58f)
01-02 03:13:59.429   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.429   573   626 I chatty  : uid=0(root) health@1.0-serv identical 1 line
01-02 03:13:59.429   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service: SUMMARY: AddressSanitizer: heap-buffer-overflow (/vendor/bin/hw/vendor.gwm.hardware.health@1.0-service+0x28427) 
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service: Shadow bytes around the buggy address:
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service:   0x001640007270: fa fa fd fd fd fd fa fa fa fa fd fd fd fd fd fd
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service:   0x001640007280: fa fa fd fd fd fd fa fa fa fa fd fd fd fd fd fd
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service:   0x001640007290: fa fa fd fd fd fd fd fd fa fa fd fd fd fa fa fa
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service:   0x0016400072a0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
01-02 03:13:59.430   573   626 I vendor.gwm.hardware.health@1.0-service:   0x0016400072b0: fa fa fd fd fd fd fa fa fa fa fd fd fd fa fa fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service: =>0x0016400072c0: fa fa 00 00 00 00 fa fa fa fa 00 00 00 00 00[fa]
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   0x0016400072d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   0x0016400072e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   0x0016400072f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   0x001640007300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   0x001640007310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service: Shadow byte legend (one shadow byte represents 8 application bytes):
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   Addressable:           00
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   Partially addressable: 01 02 03 04 05 06 07 
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   Heap left redzone:       fa
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   Freed heap region:       fd
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   Stack left redzone:      f1
01-02 03:13:59.431   573   626 I vendor.gwm.hardware.health@1.0-service:   Stack mid redzone:       f2
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Stack right redzone:     f3
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Stack after return:      f5
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Stack use after scope:   f8
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Global redzone:          f9
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Global init order:       f6
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Poisoned by user:        f7
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Container overflow:      fc
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Array cookie:            ac
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Intra object redzone:    bb
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   ASan internal:           fe
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Left alloca redzone:     ca
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service:   Right alloca redzone:    cb
01-02 03:13:59.432   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.433   573   626 I vendor.gwm.hardware.health@1.0-service: ==573==ABORTING
01-02 03:13:59.433   573   626 I vendor.gwm.hardware.health@1.0-service: 
01-02 03:13:59.433   573   626 F libc    : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 626 (health@1.0-serv), pid 573 (health@1.0-serv)
01-02 03:13:59.510 10797 10797 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
01-02 03:13:59.511   935   935 I /system/bin/tombstoned: received crash request for pid 626
01-02 03:13:59.512 10797 10797 I crash_dump64: performing dump of process 573 (target tid = 626)
01-02 03:13:59.514 10797 10797 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-02 03:13:59.514 10797 10797 F DEBUG   : Build fingerprint: 'Android/sa8155_v35_d02/sa8155_v35_d02:9/PQ1A.190105.004/zhangheyang04181326:userdebug/test-keys'
01-02 03:13:59.514 10797 10797 F DEBUG   : Revision: '0'
01-02 03:13:59.514 10797 10797 F DEBUG   : ABI: 'arm64'
01-02 03:13:59.514 10797 10797 F DEBUG   : pid: 573, tid: 626, name: health@1.0-serv  >>> /vendor/bin/hw/vendor.gwm.hardware.health@1.0-service <<<
01-02 03:13:59.514 10797 10797 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
01-02 03:13:59.514 10797 10797 F DEBUG   : Abort message too long: claimed length = 3499
01-02 03:13:59.514 10797 10797 F DEBUG   :     x0  0000000000000000  x1  0000000000000272  x2  0000000000000006  x3  0000000000000008
01-02 03:13:59.514 10797 10797 F DEBUG   :     x4  ff464d4853514e41  x5  ff464d4853514e41  x6  ff464d4853514e41  x7  7f7f7f7f7f7f7f7f
01-02 03:13:59.514 10797 10797 F DEBUG   :     x8  0000000000000083  x9  1858882d2c01f7e5  x10 0000000000000000  x11 fffffffc7fffffdf
01-02 03:13:59.514 10797 10797 F DEBUG   :     x12 0000000000000001  x13 0000000000000000  x14 0000000000000004  x15 0000000000000000
01-02 03:13:59.514 10797 10797 F DEBUG   :     x16 00000076968b12c8  x17 00000076967ef0d0  x18 0000000000000006  x19 000000000000023d
01-02 03:13:59.514 10797 10797 F DEBUG   :     x20 0000000000000272  x21 0000007696496108  x22 0000007695a8c3b8  x23 00000076964960f0
01-02 03:13:59.514 10797 10797 F DEBUG   :     x24 0000005892d4c428  x25 0000000000000001  x26 0000007696bd65e0  x27 000000000000006f
01-02 03:13:59.514 10797 10797 F DEBUG   :     x28 0000000000000000  x29 0000007692801c90
01-02 03:13:59.514 10797 10797 F DEBUG   :     sp  0000007692801c50  lr  00000076967e3bfc  pc  00000076967e3c24
01-02 03:13:59.519 10797 10797 F DEBUG   : 
01-02 03:13:59.519 10797 10797 F DEBUG   : backtrace:
01-02 03:13:59.519 10797 10797 F DEBUG   :     #00 pc 0000000000021c24  /system/lib64/libc.so (abort+116)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #01 pc 0000000000033690  /system/lib64/libclang_rt.asan-aarch64-android.so (__sanitizer::Abort()+56)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #02 pc 0000000000031250  /system/lib64/libclang_rt.asan-aarch64-android.so (__sanitizer::Die()+164)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #03 pc 00000000000a1fd0  /system/lib64/libclang_rt.asan-aarch64-android.so (__asan::ScopedInErrorReport::~ScopedInErrorReport()+316)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #04 pc 00000000000a1768  /system/lib64/libclang_rt.asan-aarch64-android.so (__asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool)+348)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #05 pc 00000000000a2594  /system/lib64/libclang_rt.asan-aarch64-android.so (__asan_report_store1+48)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #06 pc 0000000000028424  /vendor/bin/hw/vendor.gwm.hardware.health@1.0-service (vendor::gwm::hardware::health::V1_0::implementation::HealthFdbusClient::sendHeartBeat(int)+1252)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #07 pc 0000000000017dd0  /vendor/bin/hw/vendor.gwm.hardware.health@1.0-service (vendor::gwm::hardware::health::V1_0::implementation::Health::sendHeartBeat()+96)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #08 pc 000000000001a690  /vendor/bin/hw/vendor.gwm.hardware.health@1.0-service (vendor::gwm::hardware::health::V1_0::implementation::HealthThreadWorker::HandleLifeSign()+900)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #09 pc 000000000001f810  /vendor/bin/hw/vendor.gwm.hardware.health@1.0-service
01-02 03:13:59.519 10797 10797 F DEBUG   :     #10 pc 00000000000819b4  /system/lib64/libc.so (__pthread_start(void*)+36)
01-02 03:13:59.519 10797 10797 F DEBUG   :     #11 pc 0000000000023478  /system/lib64/libc.so (__start_thread+68)

根据提示内容，以及addr2line，分别找到触发ASAN的地方、被监控内存申请的地方、被监测线程创建的地方。

触发ASAN的地方，参考上述LOG WRITE of size 1 at 0x003200039678 thread T3

codes/android/out/target/product/sa8155_v35/symbols/vendor/bin/hw]
> addr2line -e ./vendor.gwm.hardware.health@1.0-service 28427 -f -a -C
0x0000000000028427
vendor::gwm::hardware::health::V1_0::implementation::HealthFdbusClient::sendHeartBeat(int)
vendor/noch/project/v3.5/sa8155/interfaces/impl/health/1.0/default/impl/src/fdbus/HealthFdbusClient.cpp:181

被监控内存申请的地方，参考上述LOG allocated by thread T3 here:

> addr2line -e ./vendor.gwm.hardware.health@1.0-service 2838b -f -a -C
0x000000000002838b
vendor::gwm::hardware::health::V1_0::implementation::HealthFdbusClient::sendHeartBeat(int)
vendor/noch/project/v3.5/sa8155/interfaces/impl/health/1.0/default/impl/src/fdbus/HealthFdbusClient.cpp:180

被监测线程创建的地方，参考上述LOG Thread T3 created by T0 here:

> addr2line -e ./vendor.gwm.hardware.health@1.0-service 1b8c7 -f -a -C
0x000000000001b8c7
std::__1::__libcpp_thread_create(long*, void* (*)(void*), void*)
external/libcxx/include/__threading_support:33

结语

如果有不懂的地方请留言，我会更新回复。 

有部分常见问题参考如下文档描述：

FAQ for ASAN on Android10/Android11/Android12/8155/8295-CSDN博客

张和阳
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
android 内存分析工具ASAN 学习
weixin_45396052的博客
07-27 4970
 简介 Asan是一款面向c/c++语言的内存报错检查工具。可以检测这些问题：使用已经释放的内存（野指针）、堆内存越界（读写）、栈内存越界读写、全局变量越界（读写）、函数返回局部变量、内存泄漏。 Asan工具主要由两部分组成分别是编译时插桩模块和运行时库 运行时库会接管malloc和free函数，malloc执行完毕后，已经分配内存的前后成为红区，并且被标记为中毒状态，而且释放的内存会被隔离出去（暂时不会分配出去）并且也会标记为中毒状态。 编译器插桩模块：加了asan相关编译选项后，代码中的每一次内存访问
KernelAddressSanitizer (KASan)内存问题分析利器解析
07-20
KASan的设计目标是为了在内核级别提供与Userspace的AddressSanitizer（ASan）类似的内存错误检测功能，包括检测使用后释放（use-after-free）、越界访问等常见问题。ASan是一个C/C++编译器插件，用于检测堆、栈和...
高通8155p平台QNX+Android9开启ASAN定位内存问题方法Android.mk与Android.bp都有
04-18
高通8155p平台QNX+Android9开启ASAN定位内存问题方法。里面有所有的Android.mk与Android.bp示例。不会写Android.mk与Android.bp，或者常有编译问题的可以下载参考，解决无法使能ASAN的问题。不会用的一定要展开下面链接看使用方法，以及编译问题示例，别啥也不懂就开始抱怨。 使用方法参考： https://blog.csdn.net/suixin______/article/details/133713263
高通8155车载芯片_地表算力最强的高通8155芯片助攻，WEY摩卡不容小觑！
热门推荐
weixin_35192322的博客
01-27 3万+
摩卡咖啡是最古老的咖啡种类之一，由于加入了巧克力、鲜奶油与牛奶，中和了咖啡本身的苦涩，备受年轻人的喜爱。前不久，WEY全新旗舰SUV被正式命名为"摩卡"，产品定位与这款咖啡的内涵有异曲同工之妙。领先科技赋能，实现跨时空智慧互联WEY品牌期望"摩卡"能像摩卡咖啡一样，可全方位满足用户对美好生活的追求，以及对未来出行方式的期待。因此，WEY摩卡采用"科技向上向美"全新的设计语言，融合力量，智慧，勇气作...
Android图像缓存与Surface初始化
LeeDuoZuiShuai的博客
05-21 1219
在Android系统中，绘制渲染与渲染管理是分开的，分别由Surface和SurfaceControl负责。Surface是SurfaceFlinger管理的一块缓存，Surface的创建依赖SurfaceControl。SurfaceControl用于管理Surface的绘制层级与获取。Surface和SurfaceControl声明在ViewRootImpl的全局成员变量中，在创建ViewRootImpl时会一起创建Surface和SurfaceControl。
[芦半山]Android native分析工具ASAN和HWASAN原理解析
嵌入式Linux
04-10 6636
ASAN和HWASAN原理解析由于虚拟机的存在，Android应用开发者们通常不用考虑内存访问相关的错误。而一旦我们深入到Native世界中，原本面容和善的内存便开始凶恶起来。这时，由...
Android工具
asan855的专栏
04-12 809
最近两个工具用的比较多，就研究了下Android的工具，通过java谢了两个小工具： 1.一键解析apk、zip、rar、jar 这个工具可以一键解析apk里面的resource，包括drawable、layout、manifest，同时将里面的dex文件转成jar,可供jd_gui阅读，很强大！其余几种格式，只要里面有dex 文件，同样生成jar文件，并将生成的结果放在同级的resul
asan：asan_symbolize.py
05-05
asan是AddressSanitizer（地址 sanitizer）的缩写，它是一个由Google开发的内存错误检测工具，主要用于检测C和C++程序中的缓冲区溢出、使用未初始化的内存、空指针解引用等常见问题。asan_symbolize.py是Address...
内存检测工具 内存问题检测就用它-华清远见.pdf
07-11
内存检测工具是C/C++开发过程中非常重要的辅助手段，用于帮助开发者发现和修复内存相关问题。内存问题在底层编程语言中尤为棘手，比如内存泄漏、越界访问、释放后使用等问题，这些问题可能导致程序崩溃或者运行不...
VS2019 16的ASAN常用选项
07-03
Goolge ASAN在VS2019 16版本以后得以支持，可以用来定位开发时遇到的大多内存问题，诸如栈、堆、全局变量越界、alloc-dealloc-mismatch、allocation-size-too-big、new-delete-type-mismatch、heap-use-after-free、...
r-4.0.3-asan-clang：一个使用支持ASAN的clang构建R 4.0.3的Docker映像
02-10
r-4.0.3-asan-clang base_dockerfile使用具有ASAN（AddressSanitizer）支持的clang base_dockerfile构建R 4.0.3。 这对于调试未通过CRAN上的ASAN检查的R软件包可能很有用。 Rpkg_dockerfile安装一组在顶部包base_image内置图像base_dockerfile 。
深入浅出Android NDK之ASan检测内存越界
taohongtaohuyiwei的博客
02-25 4214
Address Sanitizer使用注意事项
android studio中使用asan检测内存问题
技术笔记
03-29 1411
ASan 是一种基于编译器的快速检测工具，用于检测原生代码中的内存错误。 ASan 可以检测以下问题： 堆栈和堆缓冲区上溢/下溢 释放之后的堆使用情况 超出范围的堆栈使用情况 重复释放/错误释放 build.gradle 参考android官网的说明，在模块的 build.gradle 中增加arguments： android { defaultConfig { externalNativeBuild { cmake { ..
04-8155车机系统硬件平台、设备树确定（一）
吕大明白
07-17 617
SA8155新代码开机后，进行硬件平台和设备树信息确定.
Android HWASAN使用与实现原理
最新发布
专注于系统快稳省领域
07-02 815
HWASAN是在ASAN的基础上做了拓展，因此在介绍HWASAN之前先了解下ASAN.
ASAN 内存问题检查工具
见牛羊的博客
09-22 384
ASAN可以定位的内存问题有：内存越界（堆内存越界，栈内存越界，全局变量越界），内存释放后使用，读取未初始化内存，内存泄漏。
android 如何分析应用的内存（十一）——ASan
安仔的博客
07-10 1870
因为ASan需要使用各种动态库，而这些动态库在Android设备默认是没有的。因此需要将这些动态库，放入Android设备中。自定义APP的启动过程，使用wrap.sh。使用NDK提供的脚本。方法一：使用wrap.shandroid 如何分析应用的内存（七）下面只做使用说明。在AndroidManifest.xml中添加android:debuggable=“true”在build.gradle中使用 useLegacyPackaging。见android 如何分析应用的内存（七）
ASan和HWAsan在Android中使用
私房菜
06-21 3119
ASanHWASan全称版本可以在32位和64位的x86、x86-64上。从API 27(Android O MR 1)开始，Android NDK 可支持ASAN。在Android 11 之后的AOSP master中，弃用了arm64 上的平台开发ASan，改为使用HWASan。只在Android 10 及以上版本有效，且只使用于AArch64硬件平台。检测bugs要求CPU 开销（~ 2倍）代码大小开销（50% ~ 2倍）内存开销（~ 2倍）CPU 开销（~ 2倍）
基于单片机8155秒表计时器系统设计
2301_79745346的博客
04-15 1080
*单片机设计介绍，基于单片机8155秒表计时器系统设计。
android ide定位native内存泄漏
04-24
对于定位Android Native内存泄漏，有多种方法和工具可以使用，以下是一些常用的方法和工具： 1. 使用Android Studio中的Memory Profiler：在Android Studio中使用Memory Profiler可以检测Native内存泄漏，通过分析堆栈信息可以找到引起内存泄漏的代码。 2. 使用ndk-stack命令分析Native Crash：如果Native代码出现Crash，可以使用ndk-stack命令分析Crash日志，查看堆栈信息来定位内存泄漏。 3. 使用Valgrind工具：Valgrind是一种内存调试工具，可以用来定位C/C++程序中的内存问题，包括内存泄漏、越界访问等问题，通过Valgrind可以追踪内存的分配和释放情况。 4. 使用AddressSanitizer（ASan）：ASan是一种内存错误检测工具，可以用来检测C/C++程序中的各种内存错误问题，包括内存泄漏、越界访问等问题。 以上是一些常用的方法和工具，可以帮助开发者定位Android Native内存泄漏问题。
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值