NDK native crash 问题分析

最新推荐文章于 2025-02-18 07:31:46 发布
最新推荐文章于 2025-02-18 07:31:46 发布
阅读量730 收藏 1
点赞数
CC 4.0 BY-SA版权
文章标签： NDK CRASH
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/wb3553/article/details/83820666
本文详细列举了编程中常见的错误类型，如初始化错误、数组索引越界等，并通过一个具体的NativeCrash案例，展示了如何使用命令进行错误定位和调试，包括利用addr2line和objdump等工具进行反汇编分析。

常见的错误类型如下：

    初始化错误
    访问错误

    数组索引访问越界
    指针对象访问越界
    访问空指针对象
    访问无效指针对象
    迭代器访问越界

    内存泄露
    参数错误
    堆栈溢出
    类型转换错误
    数字除0错误

 

常用命令：

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Native Crash TIME: 3875438
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: ':userdebug/test-keys'
Revision: '0'
ABI: 'arm'
pid: 319, tid: 20699, name: afctrl  >>> /vendor/bin/hw/android.hardware.camera.provider@2.4-service <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x280028
    r0  a6ec4b88  r1  a7c72540  r2  00280029  r3  a724123c
    r4  a76fa000  r5  a7c72e70  r6  a7c771f8  r7  a7c72540
    r8  a6ec5490  r9  a7c72c48  r10 a7c72e70  r11 a6ec5470
    ip  a7253f40  sp  a6ec4b30  lr  a72430e4  pc  00280028

backtrace:
    #00 pc 00280028  <unknown>
    #01 pc 000030e0  /vendor/lib/libspa.so (spa_calculation+92)
    #02 pc 0002d4df  /vendor/lib/libispalg.so (caf_monitor_calc+42)
    #03 pc 00029f9f  /vendor/lib/libispalg.so (sprd_afv1_process+1530)
    #04 pc 0002655b  /vendor/lib/libispalg.so (afctrl_ctrl_thr_proc+394)
    #05 pc 000022e7  /vendor/lib/libcamcommon.so (cmr_common_routine+114)
    #06 pc 00063a55  /system/lib/libc.so (__pthread_start(void*)+22)
    #07 pc 0001df55  /system/lib/libc.so (__start_thread+22)

 

直接定位行号：

toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-addr2line -e ~/armeabi-v7a/libspa.so 30e0

也可马反汇编出来具体看：
toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-objdump -d ~/armeabi-v7a/libspa.so --start-address=0x00001248 --stop-address=0x00003620

arm-linux-androideabi-objdump –S obj/local/armeabi/libhello-jni.so > hello.asm

以上两条命令都可以实现。

系统寄存器的dump信息.

  • rX( X=[0~9] ): 代表整数寄存器
  • dX( X=[0~31]): 是浮点指针寄存器
  • fp (or r11) : 指向当前正在执行的函数的堆栈底.
  • ip (or r12) : 一个寄存器, 我也没弄明白是干啥的.
  • sp (or r13) : 当前正在执行的函数的堆栈顶.(跟fp相对应)
  • lr (or r14) : link register . 简单来说, 当当前指令执行完了, 就会从这个寄存器获取地址, 来知道需要返回到哪里继续执行.
  • pc (or r15) : program counter. 存放下一条指令的地址.

  • cpsr : Current Program Status Register. 表示当前运行环境和状态的一些字节位.

    1. Crash dump还包含PC之前和之后的一些内存字段.
    2. 最后, 是崩溃时的调用堆栈. 如果你执行的是debug版本, 还能还原一些c++代码.

 

 

 

猪太棒
关注
android 模拟crash_Android NDK模拟native crash
weixin_39797693的博客
12-19 674
最近需要模拟出一个native crash，简单来说就是声明一个native方法，然后在c/c++层实现这个方法并触发一个异常即可。由于之前没有接触过这些，所以实现起来还是花费了挺多的时间的，这期间也涉及到了很多知识点或概念，如NDK、JNI，abi以及so等。JNI的全称为Java Native Interface，即Java本地接口，类似于AIDL，提供了若干的API实现了Java和其他语言的...
安卓入门五十二 Native Crash
weixin_52735932的博客
02-10 207
此外，可以使用一些工具来帮助诊断和调试 Native Crash，例如使用 Android SDK 提供的 ndk-stack 工具来解析堆栈，使用 Clang 或 GCC 编译器提供的 Address Sanitizer、Memory Sanitizer 等工具帮助检测内存错误等。Native Crash 是指由于 JNI 代码（Java Native Interface）与底层 C/C++ 代码交互时出现错误导致的崩溃。在读写文件时，要注意数据格式的正确性，确保数据的有效性。
安卓 NDK native 方法 crash 定位分析
EricTeo
05-07 337
安卓 NDK native 方法 crash 定位分析 addr2line工具 在 ndk/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/bin 目录下 用法 addr2line [OPTIONS] addr [addr ...] OPTIONS -a --addresses：在函数名、文件和行号信息之前，显示地址，以十六进制形式 -b --target=<bfdname>：指定目标文件的格式为 bfdname -e
项目中遇到的问题总结
hs_jiephe的专栏
11-14 631
1. 日常编程时注意的小问题 1）虽然平时编程中经常使用for循环，但是写for循环的时候也要注意。比如 for (unsigned int j = beganIndex; j {      do something... } 乍看起来毫无问题，其实如果我们误把beginIndex的初始值赋成-1，问题就来了。 -1被转换成很大的正整数，导致循环失效。 2)  如果
Android APP native 崩溃分析之令人困惑的 backtrace
weixin_38166905的博客
06-02 1450
完美无缺的代码逻辑，一定能产生完美无缺的程序吗？答案是否定的。从软件的层面来看，也许只有二进制才永远不会欺骗你。 现象 近期，业务方反馈了一个奇怪的崩溃问题，认为信息不足，无法解决。 Signal: 11 (SIGSEGV), Code: 1 (SEGV_MAPERR) r0 993ff520 r1 dc3170c4 r2 00000000 r3 dabe3e0...
Android Native Crash 处理过程
Xlitol的博客
08-27 3216
native crash
android用符号表定位问题
kc58236582的博客
03-27 6468
有时候我们出现的软重启问题，只有段错误，只给你一个错误地址，没有具体信息，像这种问题我们应该怎么分析呢： 我们先举个例子： 03-15 10:53:31.636419 8989 8989 F DEBUG : pid: 11028, tid: 11046, name: android.bg >>> system_server <<< 03-15 10:53:31.636470
Android Native Crash定位
凯尼
03-11 1613
背景 当使用NDK编程时， 底层崩溃，可以断点， 日志等排查手段， 但针对复杂逻辑或代码较多时， 精确定位就显的措手不及。 本文介绍如何使用Android自带工具 ndk-stack 通过崩溃信息精准定位崩溃位置。 本文环境： Windows 10 ndk-stack工具位置: AndroidSDK/ndk-bundle/ndk-stack.cmd， Android SDK 替换成自己的Android SDK目录， 下方所涉及的ndk-stack指令均指此文件。 二、定位错误行 2.1 实时分析 实时分
native crash
王温暖的博客
12-05 1534
http://geek.youkuaiyun.com/news/detail/50839 安卓捕获RuntimeException,ANR,Native信号异常 - 简书 android 异常捕获-UncaughtExceptionHandler - 简书（UncaughtExceptionHandler） https://github.com/google/breakpad/blob/master/docs/getting_started_with_breakpad.md（Breakpad） 背景： .
Android 利用addr2line 定位 native crash问题
山高路远，看世界，也找自己~
02-18 581
addr2line bin文件，是在prebuilts目录下 ，如下所示，通过find -name aarch64-linux-android-addr2line命令，能找的到64位bin文件所在的文件目录。prebuilts$ find -name aarch64-linux-android-addr2line./gcc/linux-x86/aarch64/aarch64-linux-andr...
Android native crash debug
april_12345的博客
03-21 5729
查看crash信息 adb logcat /data/tombstones/ adb logcat中的crash信息中会指明tombstones 文件名： Tombstone written to: /data/tombstones/tombstone_06 脚本工具stack 如果有相应的源码文件， 且编译时是unstripped binaries, 将stack 信息粘贴到脚本 development/scripts/stack中， 打印detail行号。 adb pull..
Android Native crash触发原理及处理
专注于系统快稳省领域
01-10 2582
当程序执行以下操作，会触发native crash：1）程序自己调用 abort() 函数触发，用于表示出现严重的错误或异常情况，需要终止程序执行2）内存对齐错误或非法地址访问3）零除错误（除数为零），浮点溢出或下溢出等4）使用了非法的机器指令或指令参数不当而导致5）进程试图访问不允许访问的内存地址，例如访问已释放的内存，或者栈溢出等6）常见于协处理器栈错误或FPU错误7）进程试图执行未定义或不支持的系统调用8）程序的特定位置设置断点时会触发SIGTRAP信号。
Android R camera Hal启动（上）
weixin_53065050的博客
09-30 1930
文章目录前言代码流程分析总结 前言 之前准备按照camera APP调用API1/2的接口一点点的写代码流程。本地写了几篇之后发现不把camera server和hal的初始化写完，直接开始写API调用流程的话不太好写。还是从服务的初始化开始写吧。 代码流程分析 我就按照自己习惯的学习一个新的模块的思路来写。 先通过ps命令看一下当前camera hal运行的进程叫什么。 cameraserver 946 1 0 S android.hardware.camera.provider@2
Native Crash问题分析
我的博客
05-27 1412
如何使用GDB进行Crash分析以及定位
Android Camera v4l2 崩溃问题记录
转载和创作优秀的博客
04-23 2967
某车机平台，使用高通soc，基于Android P。底层通路已经由芯片供应商打通，移植的是Android v4l2的代码。 Android原生的v4l2 code路径：hardware\libhardware\modules\camera\3_4 Soc供应商复用了大部分代码+少量修改，实现了Camera功能。 问题：Camera的测试app在进行测试时，偶发camera HAL crash。概率大约50%左右。 下面记录解决步骤： Camera的流程梳理 调用过程大致如下 系统中存在2个camera.
CameraProvider进程-Android12
许浑的博客
08-09 2259
CameraProvider进程-Android12
Android Camera Provider启动流程
chengwei_peng
08-13 8544
在 Android O 中，系统启动时，就会启动 CameraProvider 服务。它将 Camera HAL 从 cameraserver 进程中分离出来，作为一个独立进程 android.hardware.camera.provider@2.4-service 来控制 HAL。 这两个进程之间通过 HIDL 机制进行通信。 这样的改动源自于 Android O 版本加入的 Treble 机制...
CameraProvider进程启动流程
转载和创作优秀的博客
05-01 2402
cameraprovider进程是Camer HAL所在进程，在分析HAL启动流程前，必须先分析下cameraprovider的启动流程 本文在此对cameraprovider的启动流程作简要的分析java rc启动脚本：linux //hardware\interfaces\camera\provider\2.4\default\android.hardware.camera.provider@2.4-service.rc service camera-provider-2-4 /vendor/bi
稳定性 Android Native ANR分析
xugd180702的博客
08-29 1068
通过debuggerd -b [pid]，可输出Native进程的调用栈，这些信息是通过解析/proc/[pid]/maps而来的。 Linux /proc/$pid部分内容详解 一、概述 当发生ANR(Application Not Response，对于Java进程可通过kill -3向目标进程发送信号SIGNAL_QUIT, 输出相应的traces信息保存到目录/data/anr/traces.txt；而对于Native进程可通过 debuggerd输出traces信息。 可通过一条命令来获取指定Na
ndk 定位crash 日志代码行数
最新发布
04-01
<think>好的，我现在需要帮助用户解决如何通过NDK生成的crash日志精确定位到对应的代码行数的问题。首先，我应该回顾一下用户提供的引用内容，看看有没有相关的信息可以利用。 用户提到了引用[2]中的内容，里面提到willCrash()方法出错在260行，这说明在crash日志中可能已经包含了具体的行号信息。但用户可能需要更详细的步骤来自己定位问题。另外，引用[3]提到定位问题需要复现步骤，而引用[4]涉及JNI方法声明和参数类型，可能和崩溃原因相关。 接下来，我需要整理NDK崩溃定位的常规方法。首先，NDK崩溃通常会生成堆栈跟踪，但如果没有符号化，这些信息是难以理解的。所以第一步应该是确保有符号表（比如.so文件附带调试信息）。然后，使用addr2line或者ndk-stack工具将地址转换为代码行数。 可能用户遇到的问题是如何使用这些工具。例如，使用ndk-stack需要将日志通过adb获取，然后运行命令进行解析。而addr2line则需要具体的地址和对应的带有调试信息的.so文件。另外，编译时需要开启调试信息，即编译选项中加入-g，否则可能无法获取行号信息。 还要考虑日志中的崩溃类型，比如空指针、内存越界等，这些可能在日志中有不同的表现。同时，需要检查JNI代码中的常见错误，比如引用管理不当、数组越界、类型不匹配等，如引用[4]中的参数类型是否正确。 另外，用户可能需要知道如何设置Android项目的调试选项，确保生成带调试符号的Native库。可能在CMake或Android.mk中配置，例如在CMakeLists.txt中添加“set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g”)。 还有，如果崩溃发生在JNI函数中，可能需要结合Java和Native的堆栈信息，查看是否有对应的JNI错误，比如使用CheckJNI来检测问题，这可能在开发阶段帮助捕获错误。 总结下来，步骤应该是： 1. 确保编译时生成调试符号。 2. 获取崩溃日志（logcat）。 3. 使用ndk-stack或addr2line解析日志中的地址。 4. 结合代码审查可能的错误点，如JNI引用、参数传递等。 需要检查用户是否遗漏了某些步骤，比如未保留带符号的so文件，或者没有正确使用工具解析。此外，可能还需要建议用户使用Android Studio的LLDB调试工具，或者配置Breakpad来捕获更详细的崩溃信息。 最后，根据用户提供的引用，尤其是引用[2]和[3]，需要强调复现步骤和精确解析日志的重要性。可能还需要提醒用户注意日志中的寄存器信息和崩溃地址对应的具体的代码段。</think>### 如何通过NDK生成的crash日志定位代码行数？ #### 1. **确保编译时包含调试符号** - 在编译Native代码时，需在`CMakeLists.txt`或`Android.mk`中添加调试符号生成选项。例如： ```cmake set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g") # 添加-g参数保留调试信息 ``` - **验证符号文件**：生成的`.so`文件应包含调试信息（可通过`file libxxx.so`检查是否包含`with debug_info`）。 #### 2. **获取完整的崩溃日志** - 使用`adb logcat`捕获崩溃日志，并过滤相关进程： ```bash adb logcat | grep "xxx" # 替换为崩溃的关键词或进程名 ``` - 典型NDK崩溃日志示例： ``` signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 backtrace: #00 pc 00001234 /data/app/lib/arm64/libnative.so (function_name+0x1234) ``` #### 3. **使用`ndk-stack`工具解析地址** - 将日志保存为文件（如`crash.log`），运行以下命令： ```bash ndk-stack -sym /path/to/obj/local/armeabi-v7a/ -dump crash.log ``` - `-sym`参数指定包含符号文件的目录（对应ABI架构）。 - **输出示例**： ``` #00 pc 00001234 libnative.so (function_name+1234) (file.cpp:260) ``` 直接显示代码文件和行号（如`file.cpp:260`）[^2]。 #### 4. **手动使用`addr2line`转换地址** - 若未集成`ndk-stack`，可用`addr2line`工具： ```bash aarch64-linux-android-addr2line -e libnative.so 00001234 ``` - 需选择对应架构的`addr2line`（位于NDK的`toolchains`目录下，如`aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin`）[^1]。 #### 5. **结合代码审查常见JNI错误** - **空指针或内存越界**：检查JNI函数中的指针操作和数组边界。 - **引用管理问题**：未正确释放局部引用（`DeleteLocalRef`）或误用全局引用。 - **参数类型不匹配**：如Java的`long`对应JNI的`jlong`，避免类型强制转换错误（参考引用[4]中的参数对应关系）。 #### 6. **使用Android Studio的LLDB调试** - 在Android Studio中启用`Debug native code`，断点调试Native代码。 - 若崩溃可稳定复现，直接运行并触发崩溃，IDE会自动定位到代码行[^3]。 --- ###
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值