如何通过so错误日志定位问题原因

最新推荐文章于 2024-10-10 20:27:48 发布
最新推荐文章于 2024-10-10 20:27:48 发布
阅读量1.7k 收藏 1
点赞数
文章标签： android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lylwo317/article/details/129785964
版权

简介

so出问题对大多数人来说不是很好定位，之前同事遇到了so的问题，当时记录了分析的过程。这里就当做案例整理分享一下。

定位问题

先放出完整的错误日志

DEBUG: pid: 30636, tid: 30636, name: com.xxx.xxx  >>> com.xxx.xxx <<<
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG: uid: 10648
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG: Cause: null pointer dereference
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x0  0000000000000002  x1  0000000000000000  x2  0000000000000002  x3  0000000000000000
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x4  0000007ff3739140  x5  000000773cb58b68  x6  28273d73686d683b  x7  0000000000000000
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x8  c695b1dd923d50de  x9  c695b1dd923d50de  x10 0000000000430000  x11 ecae000000060106
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x12 0000000000000000  x13 0000000000651110  x14 0000000000526110  x15 0000000000000000
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x16 0000007a99f2f7d0  x17 0000007789e49b88  x18 0000007a9c8c0000  x19 0000000000000000
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x20 0000000000000000  x21 00000079159b0380  x22 0000007a9c24f000  x23 00000079159b0438
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x24 000000779c11f6f8  x25 0000007a9c24f000  x26 00000000000000e7  x27 0000000000000009
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     x28 0000000000000004  x29 0000007ff3738aa0
2022-03-21 14:58:07.484 5058-5058/? A/DEBUG:     lr  0000007789e564fc  sp  0000007ff3738a90  pc  0000007789e62448  pst 0000000040001000
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG: backtrace:
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #00 pc 000000000001f448  /data/app/~~2xZag9J2zy9KNGoxlnOpiw==/com.xxx.xxx-TbIX56VZqQLnC73_TkryCQ==/lib/arm64/libmarsxlog.so (BuildId: 510be5e1f6d6cbd2f3ba8a437739e14791700304)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #01 pc 00000000000134f8  /data/app/~~2xZag9J2zy9KNGoxlnOpiw==/com.xxx.xxx-TbIX56VZqQLnC73_TkryCQ==/lib/arm64/libmarsxlog.so (BuildId: 510be5e1f6d6cbd2f3ba8a437739e14791700304)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #02 pc 000000000013740c  /data/app/~~2xZag9J2zy9KNGoxlnOpiw==/com.xxx.xxx-TbIX56VZqQLnC73_TkryCQ==/oat/arm64/base.odex (art_jni_trampoline+140)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #03 pc 0000000000134564  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #04 pc 0000000000198e94  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+204) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #05 pc 000000000030c254  /apex/com.android.art/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+376) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14 :58:07.631 5058-5058/? A/DEBUG:       #06 pc 000000000030736c  /apex/com.android.art/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+884) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #07 pc 0000000000641910  /apex/com.android.art/lib64/libart.so (MterpInvokeVirtualQuick+708) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #08 pc 0000000000132594  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_virtual_quick+20) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #09 pc 00000000017df6a0  /data/app/~~2xZag9J2zy9KNGoxlnOpiw==/com.xxx.xxx-TbIX56VZqQLnC73_TkryCQ==/oat/arm64/base.vdex (k.v.i.a.a.d.<init>+472)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #10 pc 000000000063d838  /apex/com.android.art/lib64/libart.so (MterpInvokeDirect+1164) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #11 pc 000000000012e914  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_direct+20) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #12 pc 00000000017df326  /data/app/~~2xZag9J2zy9KNGoxlnOpiw==/com.xxx.xxx-TbIX56VZqQLnC73_TkryCQ==/oat/arm64/base.vdex (k.v.i.a.a.d.a+26)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #13 pc 00000000002fed48  /apex/com.android.art/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.7983234147973590803)+268) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #14 pc 0000000000306a10  /apex/com.android.art/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+200) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #15 pc 0000000000307350  /apex/com.android.art/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+856) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #16 pc 000000000063de5c  /apex/com.android.art/lib64/libart.so (MterpInvokeStatic+548) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #17 pc 000000000012e994  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_static+20) (BuildId: 590bc1a07a50a63c196efb048a7125f4)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:       #18 pc 00000000017df00a  /data/app/~~2xZag9J2zy9KNGoxlnOpiw==/com.xxx.xxx-TbIX56VZqQLnC73_TkryCQ==/oat/arm64/base.vdex (k.v.i.a.a.c.<init>+10)
2022-03-21 14:58:07.631 5058-5058/? A/DEBUG:

#00 pc 000000000001f448就是这行函数对应的指令地址

首先分两种情况来讨论，就是有调试符号的情况和没有调试符号的情况。

有调试符号

使用addr2line确定位置，-C将C++的name mangline后的函数名还原，-f打印函数名字，-e指定符号表文件路径，18120就是pc寄存器指向的地址

╭─kevin@dell ~/AndroidStudioProjects/AndroidFFmpegLabs ‹master●› 
╰─$ addr2line -C -f -e ./ffmpeg/build/intermediates/cmake/debug/obj/armeabi-v7a/libkxffmpeg.so 18120
FFmpegDecoder::get_h264_nalu(char const*, unsigned int, unsigned char*, unsigned int*, unsigned char*, unsigned int*, bool*)
/home/kevin/AndroidStudioProjects/AndroidFFmpegLabs/ffmpeg/src/main/cpp/ffmpeg_decoder.cpp:44

这里可以看到是ffmpeg_decoder.cpp文件的第44行位置，函数名是FFmpegDecoder::get_h264_nalu(char const*, unsigned int, unsigned char*, unsigned int*, unsigned char*, unsigned int*, bool*)

没有调试符号

这里错误日志遇到的是这种情况。这种情况需要使用so反编译来定位。

使用IDA反编译so文件

具体IDA安装和使用，可以看网上文章，这里不展开讲

通过IDA可以定位出问题的位置 #00 pc 000000000001f448对应的汇编是LDR X0,[X0,#8]，如下图所示：

查看指令文档可以知道，这个是一个指针的解引用操作。但是指针地址是2，是一个无效地址。所以解引用失败了。这里说一下falt addr 0xa = 2 + 8。

再看一下调用者的位置，#01 pc 00000000000134f8，这里的话，使用F5，反汇编转成可读性更强的c语言样式，看到这个指针是从Java_com_tencent_mars_xlog_Xlog_setConsoleLogOpen这个函数参数中传递进来的

在这里插入图片描述
然后再往上层调用者追溯，也就是Java层。可以看到是下面这里。

在这里插入图片描述
继续追溯，就可以看到出错的地方了

在这里插入图片描述
这里的2就是指针2的来源。

从图中可以看到这是函数使用错误导致，本意是想设置日志等级，但是这个函数并不是用来设置日志等级的。

总结

问题的定位思路，最好的办法。就是从错误日志出发，一步一步往上追溯到错误的原因。上面的问题通过从错误日志出发，一步一步推导。最终就能找到问题原因。

心中要有一片海
关注
【Android】如何使用adb抓取Android系统的WiFi日志
码农之家
08-27 183
- 本文整理了使用adb抓取Android系统的WiFi日志的方式。
堆栈信息不打印的情况下如何定位报错原因
qq_41700030的博客
05-23 642
不知道小伙伴们有没有遇见过这种问题，即linux环境jar包执行时，执行到某一行后，后面的代码不再执行，log日志中也没有打印错误信息（try-cat堆栈信息被吃掉）。此时该怎么定位原因呢 身边的大神给介绍了个阿里的神器，arthas。 先给出官方文档： 官方文档点这里 下面是简单示例一个操作流程 下面再简单介绍一下官方文档提供的几个关键字作用 dashboard 当前系统的实时数据面板，按 ctrl+c 退出 thread 查看当前线程信息，查看线程的堆栈 jvm 查看当前J
如何定位Android NDK开发中遇到的错误
startFromWeb的专栏
12-31 943
Android NDK是什么？ Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。NDK包括： 从C / C++生成原生代码库所需要的工具和build files；
3分钟通过日志定位bug，这个技能测试人必须会
与君初相识，犹如故人归
04-17 1108
因为它返回一个日志器对象，当多次调用日志器生成函数，且日志器名称相同时，会给同一个日志器添加多个日志处理器，从而出现重复记录日志器的问题。为了解决上面的问题，在 common 文件夹下创建一个名为 __init__.py 的文件，在 common 模块被导入时会自动执行这个文件里的代码，且只会执行一次。如果将此关键字参数指定为 true，则在执行其他参数指定的配置之前，将移除并关闭附加到根记录器的所有现有处理器。默认模式为 'a'。我们的项目中，在用例执行的过程是核心，所以我们的日志也是围绕着用例的执行。
Linux大量日志，7个方法教你快速定位错误！
最新发布
weixin_71807218的博客
10-10 568
动态查看日志 从头打开日志文件 可以使用 输出某个新日志去查看 tail/head简单命令使用： 第一种方式（根据关键字查找出行号）： 用grep拿到的日志很少，我们需要查看附近的日志。我是这样做的，首先: 得到关键日志的行号 「cat -n catalina.out|tail -n +13230539|head -n 10」表示查询13230539行之后的日志则表示在前面的查询结果里再查前10条记录 第二种方式：查看指定时间段内的日志 首先要进行范围时间段内日志查询先查
Linux查看日志定位问题
weixin_30565327的博客
01-08 1988
1、定位错误关键字所在行数 cat -n test.log |grep "查找的错误关键字" 2、得到错误关键字所在行号（假设为第500行），查询错误关键字前后100行数据 cat -n test.log |tail -n +400|head -n 200 （表示从第400行开始往后查询200行数据） 转载于:https://www.cn...
MOSS中如何快速定位错误之一--通过查看日志
weixin_30920513的博客
06-25 107
MOSS中如何快速定位错误之一--通过查看日志 在MOSS中，我们看到的错误提示通常都是“Web部件不可用、Excel Web Access 　　发生错误。如果问题仍存在，请与系统管理员联系”等，非常友好，但对解决问题是一点用都没有，于是我们都需要去查日志文件才能知道具体的错误，但由于日志记录的太过“详细”，因此定位错误并不是一件轻...
解密服务器故障，如何根据日志快速定位问题？
关注微信公众号【开源Linux】，后台回复『10T』，领取10T学习资源大放送，涵盖Linux、虚拟化、容器、云计算、网络、Python、Go等书籍和视频
03-20 513
查看服务器、应用运行日志，这是每个程序员必备的工作技能，因为，日志是最好的查找出错问题在哪的途径。如果当服务器爆了，你却连如何定位错误都不知道？那么，这锅你是背定了。。。今天，我们就针对大量日志记录中，如何快速定位错误？来聊一聊。针对大量log日志快速定位错误地方动态查看日志tail-fcatalina.ou从头打开日志文件catcatalina.ou可以使用>nanjiangtes...
so库崩溃问题的定位与分析
有何不可的博客
02-02 2868
了解tombstone日志中关键信息的含义，配合addr2line或ndk-stack这两个工具的使用，那么定位分析崩溃问题就非常容易了。工欲善其事，必先利其器。
android 查看错误日志文件,Android崩溃日志获取与解析
weixin_36302350的博客
05-26 2615
今天来写点Android崩溃的东西，在我们写代码的过程中，代码写的再好再严谨，也总是会有一些程序的崩溃，对于release出去的APP，我们肯定是希望我们能够拿到崩溃的日志，便于bug的发现以及修复，在下一个版本中再修复。所以，今天我们来说说Android崩溃日志的抓取。在程序界面有一句话很流行，那就是不要重复造轮子。现在市面上有很多的崩溃日志抓取工具，比如腾讯的bugly，不管是eclipse还...
无日志定位代码段
蓬莱道人的博客
01-03 608
在生产环境中，一般情况下不会打开core文件开关，所以如果进程运行过程中core掉了，就无法找到程序的调用栈，而且此时日志文件中也没有记录core掉的原因，那么此时如何找出程序是core在哪行代码呢 ？笔者在工作中就遇到过这样一个问题。 1. 现场分析 // todo 2. 定位代码段 // todo ...
ERROR: Cannot chcon libjvm.so 日志
03-27
压缩包中的output2011-10-10_1342.txt文件可能包含了更详细的错误日志，通过分析这些日志，我们可以获取更多关于错误发生时的环境信息，如当时的用户、具体错误代码等，从而更准确地定位问题并找到解决方案。...
通过ldd,mn,gdb和core来定位so库错误信息
龚艺洋的博客
04-17 1037
ldd命令可以查看so库的依赖是否正确： ldd *.so nm命令可以查看so中使用，未定义等状态的函数和变量： https://www.cnblogs.com/LiuYanYGZ/p/5536607.html 例如，找到一个文件夹中包含“imdecode”函数的所有so库： gdb可以用来分析jni产生的core文件： https://blog.csdn.net/qiaoji...
服务器log日志大，掌握这些可正确快速定位错误！
关注微信公众号【开源Linux】，后台回复『10T』，领取10T学习资源大放送，涵盖Linux、虚拟化、容器、云计算、网络、Python、Go等书籍和视频
06-14 220
来源：blog.csdn.net/nan1996jiang/article/details/109550303今天跟大家分享日常运维工作中常用到的日志分析技巧，让你在大量的log日志中可以正确快速定位到错误！针对大量log日志快速定位错误地方动态查看日志tail-fcatalina.out从头打开日志文件catcatalina.out可以使用 >nanjiangtest.txt 输出某...
Android崩溃定位：使用addr2line和IDA Pro解析SO文件错误位置
weixin_44814196的博客
12-28 1870
在本博客中，我们深入探讨了处理Android应用崩溃问题的关键步骤，着重介绍了两个强大的工具：addr2line和IDA Pro。这两者的结合使用，有助于快速而准确地定位SO文件中的错误位置，为开发者提供了强大的调试和分析工具。
如何快速定位到报错日志中的关键信息，一招学会，赶快GET吧
龙飞的博客
11-29 4222
一般的服务器日志一个可能大的有几十上百m，小的也得几百k，里面内容是比较多的，如拿到日志没思路去看的话，下面一些办法可以让你快速定位到日志中的异常错误信息 下面的这块日志可以作为练习参考 步骤1:定位到错误信息再那个日志中(grep) 当天日志可能比较多，被切分成很多个小日志 如下图 如果出现这种情况，我们可以使用这种办法来定位错误信息再那个日志中 比如我们有相关的关键字可以直接用，用关键字匹配日志 从上面我们可以直接定位到错误信息在server.log.2022-11-14-21和server.log
运维36讲第20课：Linux 系统快速分析日志定位故障原因的 10 个方法
sucaiwa的博客
03-21 1342
通过 cat 读取整体的 access.log，然后通过 awk 进切割，只打印第一列的内容（就是 IP 的信息），后面加一个排序，这个排序的作用就是把所有的 IP 进行排序，u niq -c 就是整体地按照同样的 IP 来进行统计，并且分析出同一个 IP 请求的个数，最后按照个数进行由大到小的排序 sort -n -k 1 ，-k 1 表示第一列按照请求的个数来进行排序。这就是对于性能错误上的分析。然后再进行一个同样的排序，我们会看到这个 IP 主要请求的是哪些地址，和它们对应的请求次数。
记一次Android So错误定位
vspiders的博客
05-14 3221
在Android USB外接摄像头开发时，Android 9.0上使用到UVCcamera会遇到了一个拔掉闪退的bug，bug定位很久才找到原因，固有此文。 0x01 远程调试 USB外接摄像头因为要占用type c接口，所以必须要远程调试。这里使用mate20远程调试，需要注意一点，要在设备中开启`"仅充电"模式下允许ADB调试`。 插上数据线，之后在同一WIFI环境下。 adb ...
so库中错误信息查看
feng92
02-27 1460
查看so库中报错信息 1.报错log如下 如libFpCollect.so为自己编译运行的so文件，需定位具体的错误信息。 2.使用工具 使用ndk中自带的文件程序，路径为android-ndk-r13b\toolchains aarch64-linux-android-4.9:so库为arm架构 64位 arm-linux-androideabi-4.9:so库为arm...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值