在google breakpad中，除了有minidump之外，还有一个macrodump。这两个的区别的，minidump会将进程的dump信息保存到文件或者是发送到服务器。而macrodump的功能就是作了debuggerd的一个替代品：会将dump信 息输出到logcat中。与debuggerd的区别是由于被dump的进程的可执行文件(exe & .so)没有unwind table, 所以使用macrodump输出的信息必需通过专门的工具进行处理。
由于可执行文件没有unwind table, 所以文件的大小可以再小一些。
Project Member Reported by primi…@chromium.org, Sep 3, 2014
This is the metabug to keep track of changes to Breakpad and Chrome to support microdumps.
Currently, both Chrome for Android and WebView are able to gather stack traces coming from Android bug reports (i.e. NOT breakpad). However, Android’s debuggerd needs unwind tables to generate the stack traces in logcat. Unwind tables are expensive in term of binary size (order of MBs)
Breakpad, on the other side, doesn’t need any unwind tables in the binary that we ship on the device. Furthermore, unwind tables are not required for the functional correctness of (most) Chrome.
However, if we strip them out today, we’d lose the ability of getting meaningful stack traces for non-breakpad crash reports.
The fundamental ideas here are, essentially:
– keep linking in the breakpad code and stop shipping unwind tables.
– If the user has NOT opted for automatic breakpad crash reporting, instead of generating a minidump, dump a microdump in the system logcat.
– A microdump is a new concept introduced by this proposal. Essentially it is going to be a text-encoded minified variant of a minidump, which contains just the minimum amount of information required to get a stack trace for the crashing thread.
Link to the public design doc: http://goo.gl/B3wIRN
Breakpad microdumps for Chrome for Android
There are mainly two ways for Chrome for Android to report crashes:
A library, shipped with Chrome, which detects and uploads a minidump when a crash occurs. Breakpad isn’t always enabled. Users have to explicitly opt-in and the opt-in population can be low.
Android bug reports
Android end-users have the possibility of reporting crashing apps, either by: (2a) clicking on the report button in the crash dialog (fig. below) or (2b) filing a manual bug and attaching a bug report. In both cases, the report will contain, among the other things, a dump of the Android system logcat (a text file).
Problem: binary size (of Chrome)
Currently, both Chrome for Android and WebView are already able to gather stack traces coming from Android bug reports (i.e. NOT breakpad). So, why this discussion about breakpad?
The problem is the following: Android’s debuggerd needs unwind tables to generate the stack traces in logcat. Unwind tables are expensive in term of binary size: +1.5 Mb on arm32, +10MB on arm64.
Breakpad, on the other side, doesn’t need any unwind tables in the binary that we ship on the device. Unwind tables, in fact, are not required for the functional correctness of (most) Chrome. However, if we strip out them today, we’d lose the ability of getting meaningful stack traces for the aforementioned non-breakpad crash reports.
Overview of a possible solution
In essence, we’re today in a state where: Android can generate compact crash reports but requires a huge price in term of binary size that; breakpad can generate big minidumps for free (almost).
How can breakpad achieve this? In the very essence the difference between it and Android’s debuggerd is that the former just dumps the raw content of the stack in the minidump, postponing the stack walking/unwinding phase on the host (which has debug symbols). Android, instead, is eager to unwind the stack at crash time on the device, and this requires the information contained in the unwind tables.
The idea being discussed in this document is:
Keep linking in the breakpad code and stop shipping unwind tables.
If the user has not opted-in for Breakpad uploads, instead of generating a minidump, breakpad would dump a microdump in the logcat.
A microdump is a new concept introduced by this proposal. Essentially it is going to be a text-encoded minified variant of a minidump, which contains just the minimum amount of information required to get a stack trace for the crashing thread (see example below).
Introduce an equivalent of the minidump-stackwalk tool for microdumps, which essentially allows to unwind/symbolize those micro reports offline leveraging the symbols in the breakpad servers.
A technical proof of concept
I spent some days to make a proof-of-concept demo. The goal of the experiment was to hack a prototype of the microdump generator in the breakpad client library, write a corresponding stackwalker binary and verify that the aforementioned theory is technically feasible.
At the end of the day, it turns out that the minimum amount of data that we need to dump for having a meaningful stack trace is:
The top ~8k of the stack
The cpu context (state of the registers)
The list of mmaps (probably only the ones around pointers)
At the link below you can find an example of a microdump being reported by the prototype during a crash:
Below there is the post-processed output of the microdump-stackwalk, which conceptually closes the loop.
The prototype is essentially based on a fork of minidump_writer.cc, which strips down many redundant bits and consolidates the output in the logcat. There are clearly many optimizations possible, w.r.t of the output of the current prototype, for instance: the stack could be compressed and encoded in Base64; only the mmaps near the pointers in the stack should be necessary.
The complexity of the breakpad code changes required for generating this microdump seems low, it’s mostly refactoring / sharing code with the minidump_writer.
Below you find a (terribly hacky) CL of the prototype. Clearly it is far away from being production code, but gives a rough idea about the cardinality of the changes involved.
As visible, a lot of code can be shared with the existing minidump_writer implementation.
Similarly for the microdump-stackwalker
(example here: http://www/~primiano/webview/breakpad/microdump-stackwalk.cc)