Google breakpad是一个跨平台的崩溃转储和分析框架和工具集合。
三个主要组件
◆ client 以library的形式内置在你的应用中，当崩溃发生时写 minidump文件
◆ symbol dumper 读取由编译器生成的调试信息（debugging information），并生成 symbol file
◆ processor 读取 minidump文件 和 symbol file,生成可读的c/c++ Stack trace.
简单来说就是一个生成 minidump，一个生成symbol file，然后将其合并处理成可读的Stack trace。
MiniDump文件格式
minidump文件格式是由微软开发的用于崩溃上传，它包括：
◆当dump生成时进程中一系列executable和shared libraries, 包括这些文件的文件名和版本号。
◆进程中的线程列表，对于每个线程，minidump包含它在寄存器中的状态，线程的stack memory内容。这些数据都是未解析的字节流，Breakpad client通常没有调试信息（debugging information）能生成函数名，行号，甚至无法确定stack frame的边界。
◆其他收集关于系统的信息，如：处理器，操作系统高版本，dump的原因等等。
Breakpad在所有平台上（windows/linux等）都统一使用minidump文件格式，而不使用core files，原因是因为：
◆ core files可能很大，而minidump比较小。
◆ core files文档不全
◆ 很难说服windows机器去生成core files，但可以说服其他机器来生成minidump文件。
◆ breakpad只支持一种统一的格式会比较简单，而不是同时支持多种格式。
Symbols文件格式
symbols文件是基于纯文本的，每一行一条记录，每条记录中的字段以一个空格作为分隔符，每条记录的第一个字段表示这一行是什么类型的记录。
记录类型：
◆ 模块记录：MODULE operatingsystem architecture id name
◆ 文件记录：FILE number name
◆ 函数记录：FUNC address size parameter_size name
◆ 行号记录：address size line filenum
◆ PUBLIC记录：PUBLIC address parameter_size name
◆ STACK WIN
◆ STACK CFI
不同平台的实现原理
默认情况下，当崩溃时breakpad会生成一个minidump文件，在不同平台上的实现机制不一样：
◆在windows平台上，使用微软提供的 SetUnhandledExceptionFilter() 方法来实现。
◆在OS X平台上，通过创建一个线程来监听 Mach Exception port 来实现。
◆在Linux平台上，通过设置一个信号处理器来监听 SIGILL SIGSEGV 等异常信号。
当minidump被生成后，在不同平台上也使用不同的机制来上传crash dump文件。
异常处理机制
提供两种不同的异常处理机制：
◆ 同进程(in-process)
◆ 跨进程(out-precess)
因为在崩溃的进程写minidump文件是不安全的，所以三个平台（windows、linux、mac os）都提供跨进程的异常处理机制。