![](https://tbr8.org/wp-content/uploads/2017/11/breakpad-1.png)
主要包括三个部分
- dumpSyms 负责 读取 用户开发应用中的debug信息 并生成特定的符号文件 https://github.com/google/breakpad/blob/master/docs/symbol_files.md
- client 在崩溃系统中也就是指的崩溃上报的sdk 负责抓取当前线程和当前载入的库 生成 minidump文件
- processor 也就是崩溃系统中的mnidump_stackwalk 读取minidump文件 找到合适的符号文件 产生一个人类可读的c/c++调用栈
minidump文件格式
一开始是微软为了崩溃处理 自行开发的
minidump文件包含
-
当前进程所载入的库 包括库名和版本
-
当前进程包含的线程,线程寄存器状态,栈内存内容 这些数据都是字节流 没有函数名称和代码行号
-
其他的一些操作系统的版本之类的
breakpad 使用minidump格式跨平台 相比于coredump文件 体积更小
breadpad通过拦截crash 然后调用breakpad library产生minidump file
windows上 SetUnhandledExceptionFilter
mac上通过mach exception port
![](https://tbr8.org/wp-content/uploads/2017/11/52416362-626C-48F6-9EC5-C93D83C74F37-1.png)
对于linux系统来说 就是注册一个signal handler 对像SIGKILL SIGSEGV这样的信号
关于上传minidump文件 各个platform也稍有不同
Windows & Linux, a separate library of functions is provided that can be called into to do the upload. On OS X, a separate process is spawned that prompts the user for permission, if configured to do so, and sends the file.
In-process vs. out-of-process
进程内处理还是进程外处理
进程外好一点 进程内不安全 慢 处理栈可能被改写
进程内上报
window 進程外
![](https://tbr8.org/wp-content/uploads/2017/11/8030A604-5B48-4EFF-B923-158608E574CF-1.png)
linux 利用系統調用 clone 一份crash process
and then uses
1 | ptrace() |
and the
1 | /proc |
file system to retrieve the information required to write the minidump
—
启动一个daemon 来处理所有process的crash
![](https://tbr8.org/wp-content/uploads/2017/11/C9BF1DFB-E9C0-4BBF-B270-8A5A62AC63C5-1.png)