Linux开发coredump文件分析实战分享
免费下载资源
前言：
coredump 分析是嵌入式linux开发中经常使用的方法，我们也可以经常看到相关的使用教程，但是网上很少有一个多线程应用coredump文件的分析过程介绍，今天我来分享一下自己实际使用中一些案例，来给大家进行一下分享，受限于代码和篇幅。我此处只描述一些我认为比较有特色的问题，工作中遇到很多的coredump文件都可以用这些框架思维去解决。
作者：良知犹存
转载授权以及围观：欢迎关注微信公众号：羽林君
或者添加作者个人微信：become_me
情节介绍:
我在调试一个功能时候,产生了一些coredump文件 正好出现了不一样的程序报错的情况 ，正好借这个机会给大家分享一下。一般coredump文件产生的原因有空指针、数组越界、多线程多次释放、堆栈溢出等等。这里我就是按照自己遇到的情况，找了一些比较有代表性的给大家做一个简单的分享。
首先我们对应调试的话 使用gdb调试 先得熟悉一下gdb调试得各个命令，以下两篇文章是我之前进行gdb工作的描述，
所以本文就不多做赘述，只进行对应coredump文件分析时候，我们需要进行查看分析的实战。
首先我们用带有debug信息的可执行文件进行调试
gdb executable_file coredump_file示例一：指针初始化失败
进入之后第一件事情就是 使用 bt命令查看堆栈信息
在这个coredump文件中，我们很容易看到一个函数的传入地址和类成员函数有明显的数据区别。如此明显的部分我们就可以直接下定论之后，进行细节查看。
f n通过帧编号来选择帧，帧编号可以通过 bt 命令来查看。
我们查看对应的第 17帧的堆栈信息
通过上面截图我们可以看到在第17帧中 this这个类实体化的地址出现了问题。
为了对比我们又查看了对应20帧的堆栈信息以及对应帧的详细信息
然后我们需要确认该指针是什么什么出现问题的，进行第20帧数据的详细查看。其中我们用p命令查看该类下面的对应的和17帧this的关系，确认gyro_在这个函数执行的时候，地址是否正确。
从上面来看在此处函数执行的时候，对应的gyro的地址还没有变成错误的0x1388。
从这里我们基本可以确认到，函数从 第20帧对应位置执行之后再到17帧的函数的时候，执行函数的地址发生了改变 然后开始进入校对代码的环节。
这个时候校对不是看代码执行的具体情况，因为发生问题的部分已经是被修改了指针地址。所以我们需要从全局去看这个实体类被进行实体化和释放操作的地方。
最终找到了一个出现线程调用先后顺序导致变量没有准备好，出现的死机情况。
示例二：另一个指针问题
进入之后第一件事情 使用 bt命令查看堆栈信息
这个coredump文件在使用bt命令之后发现 此处的堆栈信息看上去都很正常，无法显示出代码在哪里了出现了问题。
这个时候我们就要考虑多线程时候，堆栈信息不一定直接捕获到对应线程，我们需要打开所有线程里面的堆栈信息。
thread apply all bt
除了bt大家也可以打印自己需要的其他信息
thread apply all command //所有线程都执行命令
info threads 显示当前可调试的所有线程
thread ID 切换当前调试的线程为指定ID的线程
对应打印出所有线程的堆栈信息之后，我们就进行一点点查看，但是如果你的代码定义了 信号处理函数，例如我使用了 handle_exit进行处理，然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数，再往回查看程序执行的过程。
此时我们发现led一个实体化类的的初始地址出现了问题，最后校验代码，发现了这个bug。
或者我们也可以进行 命令
thread 29 切换gdb调试线程
再用bt命令一点点查看信息
示例三：内存溢出
进入之后第一件事情 使用 bt命令查看堆栈信息
此时发现当前堆栈信息也无法进行定位到问题。
然后我们使用了thread apply all bt 但是第一遍我们没有看到对应的hand_exit函数
然后我们使用 info locals查看一下保存的本地变量的信息
info f addr打印通过addr指定帧的信息。info args打印函数变量的值。
info locals打印本地变量的信息。
info catch打印出当前的函数中的异常处理信息。
本地变量也没有一些明显表示出指针错误、数据越界的一些显示。
所以 我们又使用 p 指令打印帧信息里面保存的变量信息。
通过打印这些我们认为出错率比较高的变量信息，可以辅助我们进行判断。不过本次打印也没办法确认到问题位置。
然后我们重新看全部线程的堆栈信息。最终看到了一个异常的参数，这个值很大，有些异常。
紧接着我们进行查看对应的源码位置，因为是C++的库，所以我们直接看编译位置的代码。
先看 第7 帧 信息显示的stl_algobase.h:465
打开对应的代码位置之后发现**__n**参数 是进行分配空间的数量的参数。
再次查看执行前后的 stl_vector.h:343
而现在传入的__n大约是大于亿的单位值，而代码实际工作的位置是不需要这么大的空间分配的。所以确认是此处有问题，对照代码执行的位置以及对应变量的全局使用情况，最后基本定性为队列在多线程使用中，锁没有使用好，导致多个线程在极端情况下，输出和输入操作会对同一个区域进行，导致了此次代码死机。
结语
这就是我分享的项目中分析coredump文件的情况，如果大家有更好的想法和需求，也欢迎大家加我好友交流分享哈。
此外除了我文中使用的这些命令，大家也可以辅助gbd调试的更多命令来检查我们coredump文件。例如查看汇编代码等等。网上关于gdb调试命令的文章还是有很多，大家也可以辅助看其他文章命令使用。
作者：良知犹存，白天努力工作，晚上原创公号号主。公众号内容除了技术还有些人生感悟，一个认真输出内容的职场老司机，也是一个技术之外丰富生活的人，摄影、音乐 and 篮球。关注我，与我一起同行。
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧推荐阅读
【3】CPU中的程序是怎么运行起来的 必读
本公众号全部原创干货已整理成一个目录，回复[ 资源 ]即可获得。
GitHub 加速计划 / li / linux-dash
10.39 K
1.2 K
下载
旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。
更多推荐
8
0- 0
已为社区贡献10条内容
所有评论(0)