前言：

coredump 分析是嵌入式 linux 开发中经常使用的方法，我们也可以经常看到相关的使用教程，但是网上很少有一个多线程应用 coredump 文件的分析过程介绍，今天我来分享一下自己实际使用中一些案例，来给大家进行一下分享，受限于代码和篇幅。我此处只描述一些我认为比较有特色的问题，工作中遇到很多的 coredump 文件都可以用这些框架思维去解决。

作者：良知犹存

转载授权以及围观：欢迎关注微信公众号：羽林君

或者添加作者个人微信：become_me

情节介绍:

我在调试一个功能时候,产生了一些 coredump 文件 正好出现了不一样的程序报错的情况 ，正好借这个机会给大家分享一下。一般 coredump 文件产生的原因有空指针、数组越界、多线程多次释放、堆栈溢出等等。这里我就是按照自己遇到的情况，找了一些比较有代表性的给大家做一个简单的分享。

首先我们对应调试的话 使用 gdb 调试 先得熟悉一下 gdb 调试的各个命令，以下两篇文章是我之前进行 gdb 工作的描述，

一文入门Linux下gdb调试(一)

一文入门Linux下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 //所有线程都执行命令

对应打印出所有线程的堆栈信息之后，我们就进行一点点查看，但是如果你的代码定义了 信号处理函数，例如我使用了 handle_exit 进行处理，然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数，再往回查看程序执行的过程。

此时我们发现 led 一个实体化类的的初始地址出现了问题，最后校验代码，发现了这个 bug。

示例三：内存溢出

进入之后第一件事情 使用 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  ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧

推荐阅读

【1】在球场上我向人民币玩家低了头

【2】嵌入式底层开发的软件框架简述

【3】CPU中的程序是怎么运行起来的 必读

【4】cartographer环境建立以及建图测试

【5】设计模式之简单工厂模式、工厂模式、抽象工厂模式的对比

本公众号全部原创干货已整理成一个目录，回复[ 资源 ]即可获得。