C/C++程序最棘手的时候就是一个字“挂”，总是经常和不经常的挂掉，尤其是那些线上的不经常挂的情况，光看日志定位问题真的很难。
为解决C挂挂的问题，有必要提供一个跨平台的crash处理系统，目前已知的支持平台有windows 、Linux、 OS X 、android、等待。
下面就来看看Google自己用的系统：Breakpad
最好的介绍莫过于谷歌自己的：
谷歌的介绍：http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad
谷歌翻译-》本人修改版：（不一定准确）minidump-》小型转储
介绍
Breakpad是一个库和工具套件可以让你发布的应用程序（把编译器提供的调试信息剥离掉的）给用户，记录了崩溃紧凑的“dump”文件，发送回您的服务器，并从这些minidump产生C和C++堆栈踪迹。Breakpad可以根据请求使没有崩溃的程序也可以写出minidump。
目前使用Breakpad的有谷歌浏览器，火狐，谷歌的Picasa，卡米诺，谷歌地球，和其他项目。
Breakpad有三个主要组件：
转储文件的格式是由微软开发的类似存储的文件，崩溃便利上传。一个minidump文件包含：
Breakpad在所有平台上使用Windows dump文件，而不是传统的core文件，有以下几个原因：
通过调用到Breakpad库生成一个minidump。默认初始化Breakpad时，安装了一个异常/信号handler，崩溃时可写一个minidump到磁盘。在Windows上，这是通过SetUnhandledExceptionFilter()实现；在 OS X上，这是通过创建一个线程，等待的Mach exception端口，在Linux上，这是通过安装一个信号handler来应对程序的各种异常情况，如SIGILL，SIGSEGV等。
一旦生成minidump，每个平台都有一个略有不同的方式上传的崩溃dump。在Windows和Linux上，提供一个单独的函数库，可以被称为做upload。在OS X上，一个单独的进程产生，提示用户是否允许，如果同意这样做则发送文件。
进程内与进程外的异常处理——进程内写minidump通常被认为是不安全的，关键处理数据结构可能已经被破坏，异常处理程序运行所处的堆栈或可能已经被覆盖，等等。所有3个平台都支持“进程外”异常处理。
所有的客户端代码访问谷歌计划在http://code.google.com/p/google-breakpad 。 是在src目录下的以下目录结构：
（在其他目录）
适用于所有平台。src/tools/{platform}/dump_syms是一个工具，可以读取每个平台的调试信息（例如，OS X / Linux操作系统，DWARF和STABS，以及Windows，PDB文件），和产生一个Breakpad的符号文件。应在二进制程序剥离符号之前（比如OS X/Linux）运行此工具，需要存储dump在处理器可以找到的地方。还有另一种工具，symupload，可以上传符号文件。如果你写了一个服务器，可以接收它们。
还是来自Google：http://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide
由于有代码等原因，本人直接按自己理解，白话，E文好的直接点链接看。
| 怎样把Breakpad加入你的程序呢,E文是母语的直接点连接。
This document is an overview of using the Breakpad client libraries on Linux. 先编译库 |
源码目录下运行
./configure && make
生成 src/client/linux/libbreakpad_client.a
把Breakpad整合进程序
首先，把libbreakpad_client.a链接进你的程序，把src目录include进去，诸如：（g++ -g test.cc -I. -L./client/linux/ -lbreakpad_client -lpthread -o test）。
#include "client/linux/handler/exception_handler.h"
在程序刚开始的时候实例化google_breakpad::MinidumpDescriptor和google_breakpad::ExceptionHandler 这两个东东。dump目录可改，dump时可设回调来获取dump信息，示例代码如下：
static bool dumpCallback(const google_breakpad::MinidumpDescriptor& descriptor, void* context, bool succeeded){ printf("Dump path: %s\n", descriptor.path()); return succeeded;}void crash(){ volatile int* a = (int*)(NULL); *a = 1;}int main(int argc, char* argv[]){ google_breakpad::MinidumpDescriptor descriptor("/tmp"); google_breakpad::ExceptionHandler eh(descriptor, NULL, dumpCallback, NULL, true, -1); crash(); return 0;}
编译运行会产生dmp在/tmp下，ExceptionHandler 结构的信息参考 in the exception_handler.h source file.
回调做的工作越少越好，因为crash的程序本身就不安全，分配内存或调用另一个库里的函数都是不安全的，使用fork另起个进程来做事才是最安全的. 如果必须在crash时使用回调参考some simple reimplementations of libc functions,避免直接调用libc, 比如a header file for making Linux system calls (insrc/third_party/lss) 避免使用动态库.(其实就是提倡使用系统调用system call而已，原理就是使用子进程来do something)
如何发送dump文件
参考 some HTTP upload sourcea minidump upload tool.
处理符号文件
为了产生有用的堆栈跟踪, Breakpad需要你把二进制中的调试符号转成text-format symbol files. 首先，编译时必须用-g 包含调试符号。其次编译这个工具dump_syms ，这个在上边make的时候一起生成好了。
$ google-breakpad/src/tools/linux/dump_syms/dump_syms ./test > test.sym
像下面这样搞，就是搞出个特定的目录来，目录名是head命令 查看 test.sym第一行得出来的，然后把test.sym搞进去，最好复制。
$ head -n1 test.symMODULE Linux x86_64 6EDC6ACDB282125843FD59DA9C81BD830 test$ mkdir -p ./symbols/test/6EDC6ACDB282125843FD59DA9C81BD830$ mv test.sym ./symbols/test/6EDC6ACDB282125843FD59DA9C81BD830
symbolstore.py 这个 Mozilla 的脚本能搞定上边几步。
Usage: symbolstore.py <params> <dump_syms path> <symbol store path> <debug info files or dirs>
例：./symbolstore.py ./tools/linux/dump_syms/dump_syms symbols test
处理minidump来生成堆栈信息
还是用工具minidump_stackwalk 来搞
google-breakpad/src/processor/minidump_stackwalk minidump.dmp ./symbols
在 stderr输出了很长的输出信息，在stdout输出了堆栈信息，然后你就可以定位挂在哪里了。
示例：
[root@CentOS src]# ./processor/minidump_stackwalk 5ee28168-f798-caba-749b962b-312eaf19.dmp ./symbols/
2012-12-13 17:15:29: minidump_processor.cc:281: INFO: Processing minidump in file 5ee28168-f798-caba-749b962b-312eaf19.dmp
2012-12-13 17:15:29: minidump.cc:3832: INFO: Minidump opened minidump 5ee28168-f798-caba-749b962b-312eaf19.dmp
2012-12-13 17:15:29: minidump.cc:3943: INFO: Minidump not byte-swapping minidump
2012-12-13 17:15:29: minidump.cc:4309: INFO: GetStream: type 1197932545 not present
2012-12-13 17:15:29: minidump.cc:4309: INFO: GetStream: type 1197932546 not present
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /workspace/Breakpad/trunk/src/test
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /lib64/ld-2.12.so
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /lib64/libc-2.12.so
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /lib64/libpthread-2.12.so
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /lib64/libm-2.12.so
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /lib64/libgcc_s-4.4.6-20120305.so.1
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for /usr/lib64/libstdc++.so.6.0.13
2012-12-13 17:15:29: minidump.cc:2011: INFO: MinidumpModule could not determine version for linux-gate.so
2012-12-13 17:15:29: minidump_processor.cc:128: INFO: Minidump 5ee28168-f798-caba-749b962b-312eaf19.dmp has CPU info, OS info, no Breakpad info, exception, module list, thread list, no dump thread, and requesting thread
2012-12-13 17:15:29: minidump_processor.cc:166: INFO: Looking at thread 5ee28168-f798-caba-749b962b-312eaf19.dmp:0/1 id 0x38f5
2012-12-13 17:15:29: minidump.cc:308: INFO: MinidumpContext: looks like AMD64 context
2012-12-13 17:15:29: minidump.cc:308: INFO: MinidumpContext: looks like AMD64 context
2012-12-13 17:15:29: source_line_resolver_base.cc:220: INFO: Loading symbols for module /workspace/Breakpad/trunk/src/test from memory buffer
2012-12-13 17:15:29: simple_symbol_supplier.cc:193: INFO: No symbol file at ./symbols//libc-2.12.so/77DDBBF2BF8AFBECA0C59BBCBA94D1150/libc-2.12.so.sym
2012-12-13 17:15:29: basic_code_modules.cc:88: INFO: No module at 0x0
2012-12-13 17:15:29: basic_code_modules.cc:88: INFO: No module at 0x7fff6c4b8bc8
2012-12-13 17:15:29: basic_code_modules.cc:88: INFO: No module at 0x100000000
2012-12-13 17:15:29: minidump_processor.cc:275: INFO: Processed 5ee28168-f798-caba-749b962b-312eaf19.dmp
2012-12-13 17:15:29: minidump.cc:3804: INFO: Minidump closing minidump
Operating system: Linux
0.0.0 Linux 2.6.32-279.11.1.el6.x86_64 #1 SMP Tue Oct 16 15:57:10 UTC 2012 x86_64
CPU: amd64
family 6 model 42 stepping 7
1 CPU
Crash reason: SIGSEGV//挂掉类型
Crash address: 0x0
Thread 0 (crashed)//挂掉线程id
0 test!crash() [test.cc : 10 + 0x4]//代码： *a = 1; //a是一个int*的指针，值为NULL，给NULL赋值1，必须挂，源码的第10行，从左到右第四个字符的位置挂了，即a。
rbx = 0x00007fff6c4b8a90 r12 = 0x0000000000401a00
r13 = 0x00007fff6c4b8bc0 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x0000000000401b2d
rsp = 0x00007fff6c4b89e0 rbp = 0x00007fff6c4b89e0
Found by: given as instruction pointer in context
1 test!main [test.cc : 16 + 0x4]
rbx = 0x00007fff6c4b8a90 r12 = 0x0000000000401a00
r13 = 0x00007fff6c4b8bc0 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x0000000000401c29
rsp = 0x00007fff6c4b89f0 rbp = 0x00007fff6c4b8ae0
Found by: call frame info
2 libc-2.12.so + 0x1ecdc
rbx = 0x0000000000000000 r12 = 0x0000000000401a00
r13 = 0x00007fff6c4b8bc0 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x0000003d64e1ecdd
rsp = 0x00007fff6c4b8af0 rbp = 0x0000000000000000
Found by: call frame info
3 test!crash() [test.cc : 11 + 0x1]
rip = 0x0000000000401b35 rsp = 0x00007fff6c4b8b10
Found by: stack scanning
Loaded modules:
0x00400000 - 0x00412fff test ??? (main)
0x3d64a00000 - 0x3d64a1ffff ld-2.12.so ???
0x3d64e00000 - 0x3d6518dfff libc-2.12.so ???
0x3d65600000 - 0x3d65818fff libpthread-2.12.so ???
0x3d65a00000 - 0x3d65c83fff libm-2.12.so ???
0x3d6a600000 - 0x3d6a815fff libgcc_s-4.4.6-20120305.so.1 ???
0x3d6c600000 - 0x3d6c8f0fff libstdc++.so.6.0.13 ???
0x7fff6c4f9000 - 0x7fff6c4f9fff linux-gate.so ???
首先产生工程文件，下载python2.7，windows二进制版本安装好，设好Path环境变量。
然后Dos进入Breakpad目录，设置好使用vs2010，使用gyp脚本生成sln工程文件。
set GYP_MSVS_VERSION=2010
src\tools\gyp\gyp.bat --no-circular-check src\client\windows\breakpad_client.gyp
src\client\windows下边有生成好的sln文件，打开sln，Debug编译，在Debug下边有生成好的exception_handler.lib，和exception_handler.h这两个加入你的项目中。
#include "exception_handler.h"//使用时include头文件
handler = new ExceptionHandler(const wstring& dump_path,
FilterCallback filter,
MinidumpCallback callback,
void* callback_context,
int handler_types,
MINIDUMP_TYPE dump_type,
const wchar_t* pipe_name,
const CustomClientInfo* custom_info); The parameters, in order, are:
src/client/windows/tests/crash_generation_app/* 有OOP方式的示例。
说白了，和linux一样，在程序开始时，先new一个ExceptionHandler，同时也决定了minidump的产生方式。
C盘下建立Dumps目录，打开src\client\windows\tests\crash_generation_app目录下面的sln，菜单栏选择client，里边有多种 crash 方式，你可选择一种。
然后Dumps里可以找到挂掉的dmp文件，复制到src\client\windows\tests\crash_generation_app\Debug下面，里面有：crash_generation_app.exe crash_generation_app.pdb
双击dmp运行调试，点击右上角的“使用 仅限本机 进行调试”，OK，运行了，挂了，选择“中断”，然后可以在“调用堆栈”窗口里找到挂的位置。可能挂在系统库里，你需要在
“调用堆栈”窗口里找到你的代码行，从上往下找到第一个你的代码行，双击即可定位，可以看到printf(NULL)。
Origin: Google Breakpad 之一，跨平台crash 处理上报系统简介_wpc320的专栏-CSDN博客