Linux下Breakpad的几个主要工具

1. 对传进来的函数参数最好在开始进行检查，尤其是指针等。

 

 

几个工具：

1. 产生minidump文件：在程序入口处实例化 ExceptionHandler 
2. 产生symbol文件：
1. 程序运行调试时须带调试信息 -g
2. 调用工具：dump_syms，产生symbol文件
3. PS：有一个相关的python脚本能完成这些工作 symbolstore.py (原来应用于火狐浏览器的一个dump，不知道是否适用，还没研究)
3. minidump文件和symbol文件的上传到服务器：some HTTP upload source和a minidump upload tool
4. minidump文件的分析：
1. 调用的工具：minidump_stackwalk
2. 分析结果说明：系统的基本信息，OS、CPU等；奔溃理由；奔溃地址；堆栈信息；加载的模块等。自己的一个minidump文件截图如下，终端提示信息中有缺少libc-2.5.so的symbol文件等，我个人感觉会影响结果的分析，查到一个资料Decoding Crash Dumps 的Get the debugging symbols部分也有提到相关信息，照做后发现失败，原因未知。而不管这个问题分析出来的结果其实已经提供了我们需要的信息，在堆栈部分已经包含了奔溃的代码行。
5. 就后台分析的一些想法：
• 总结：这段时间本来的想法是通过调试breakpad提供的分析代码，找到有用的接口，然后自己重写一下，不过后来发现似乎没这个必要：1. 工程调试很麻烦，依赖的库太多，更别说调用它的接口；2. 公用接口其实并不好调用（不知专业说法）；3. 已经将这些分析的代码整合成一个比较好用的工具，个人感觉提供的分析结果信息已经够了。

• 

• 思路：
• 上传带有调试信息的文件到服务器
• 程序奔溃上传minidump文件到服务器
• 服务器寻找到相应文件，调用 dump_syms 产生symbol文件
• 后台调用 minidump_stackwalk完成分析
• 问题：
• 之前所有的操作都是终端手动完成 ，由终端转到后台自动完成的可行性