Google Breakpad · 基础介绍

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）都提供跨进程的异常处理机制。