tree: 179c57e908f1ccc60d298e1f186b6c36d7d73f9f [path history] [tgz]
  1. meta/
  2. BUILD.gn
  3. crashpad_analyzer_impl.cc
  4. crashpad_analyzer_impl.h
  5. main.cc
  6. MAINTAINERS
  7. README.md
  8. report_annotations.cc
  9. report_annotations.h
bin/crashpad/README.md

Crash reporting

For development, it is often easier to dump the crash information in the logs as the crash happens on device. This is today the default behavior. For devices in the field, we want to be able to send a report to a remote crash server instead as we might not have access to the devices' logs. We use Crashpad as the third-party client library to talk to the remote crash server. “Enabling Crashpad” is our current terminology for saying that we are automatically uploading crash reports to a remote server instead of dumping the info in the logs.

To enable Crashpad, you need to specify an additional build flag:

(host)$ fx set ... --args=enable_crashpad=true

Adding report annotations

We collect various info in addition to the stack trace, e.g., process names, board names, that we add as annotations to the crash reports. To add a new annotation, simply add a new field in the map returned by ::fuchsia::crash::MakeAnnotations().

Testing

To test your changes, make sure to first build with Crashpad enabled. Then on a real device, we have two helper programs to simulate a kernel crash and a C userspace crash. After running each one of them (see commands in sections below), you should then look each time for the following line in the syslog:

(host)$ fx syslog --tag crash
...
successfully uploaded crash report at $URL...
...

Click on the URL (contact frousseau if you don't have access and think you should) and check that the report matches your expectations, e.g., the new annotation is set to the expected value.

Kernel crash

The following command will cause a kernel panic:

(target)$ k crash

The device will then reboot and the system should detect the kernel crash log, attach it to a crash report and try to upload it. Look at the syslog upon reboot.

C userspace crash

The following command will cause a write to address 0x0:

(target)$ crasher

You can immediately look at the syslog.

Question? Bug? Feature request?

Contact frousseau, or file a bug or a feature request.