前言：
在嵌入式linux开发中，分析coredump文件是一种常用的方法，我们经常可以在网络上找到相关的使用教程。然而，很少有介绍如何分析多线程应用程序的coredump文件的文章。今天我来分享一些我在实际使用中遇到的案例，希望能给大家提供一些帮助。由于代码和篇幅的限制，我只会描述我认为比较有特色的问题，并以框架思维去解决许多遇到的coredump文件的情况。
作者：良知犹存
转载授权以及围观：欢迎关注微信公众号：羽林君
或者添加作者个人微信：become_me
情节介绍:
在调试一个功能时，我产生了一些coredump文件，并且出现了不同的程序报错情况。通过这个机会，我想分享给大家。一般而言，coredump文件产生的原因可能是空指针、数组越界、多线程多次释放、堆栈溢出等等。在这里我按照自己遇到的情况挑选了一些具有代表性的问题，与大家分享一些简单的解决思路。
首先，要进行相应的调试，我们需要使用gdb工具。在开始分析coredump文件之前，需要熟悉一下gdb的各个命令。下面是我之前写的两篇关于gdb调试的文章：
一文入门Linux下gdb调试(一)
一文入门Linux下gdb调试(二)
因此，本文将不再赘述这些内容，只着重介绍在分析coredump文件时，我们需要进行的实际操作。
首先，我们需要使用带有调试信息的可执行文件进行调试。
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命令之后发现 此处的堆栈信息看上去都很正常，无法显示出代码在哪里了出现了问题。
这个时候我们就要考虑多线程时候，堆栈信息不一定直接捕获到对应线程，我们需要打开所有线程里面的堆栈信息。
可以实现用户的在线注册、登陆后可以添加图书、购买图书，可以对图书类别、出版社、价格等进行饼图分析默认帐号/密码：51aspx/51aspx该系统采用三层接口开发，App_Code下为三层结构的代码文件，适合三层入门者学习使用数据绑定控件使用的是GridView，顶部公用文件采用了UserControl用户控件调用DB_51aspx下为Sql数据库文件，附件即可【该源码由51aspx提供】
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调试命令的文章还是有很多，大家也可以辅助看其他文章命令使用。
