汤不热吧
主要包括三个部分
- 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
对于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 進程外
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
