| # Feedback |
| |
| For development, it is often easier to dump the crash information in the logs as |
| the crash happens on device. For devices in the field, reports may be sent to a |
| remote crash server, as access to the devices' logs might not be available. |
| The `fuchsia.net.http.Loader` protocol is used to talk to the remote crash |
| server. Whether reports are uploaded is controlled via |
| [Assembly](https://fuchsia.dev/fuchsia-src/concepts/software_assembly/overview). |
| |
| ## Testing |
| |
| To test your changes, on a real device, we have some unit tests and some helper |
| programs to simulate various crashes. For the helper programs, you first need to |
| apply a developer override to enable uploads on an eng device. For example, the |
| userdebug config enables crash report uploading if the privacy settings also |
| have it enabled. |
| |
| ### Developer overrides |
| |
| First, define one or more developer overrides in `//local/BUILD.gn`. This file |
| is Git-ignored so you can add it once and only use/modify as needed: |
| |
| ``` |
| import("//build/assembly/developer_overrides.gni") |
| |
| assembly_developer_overrides("feedback_userdebug_config") { |
| developer_only_options = { |
| forensics_options = { |
| build_type_override = "userdebug" |
| } |
| } |
| } |
| ``` |
| |
| You can apply an override via `fx set` using a label from `//local/BUILD.gn`, |
| such as: |
| `product_assembly_overrides_label = "//local:feedback_userdebug_config"`. |
| |
| Alternatively, overrides can be specified in-line in args.gn: |
| |
| ``` |
| product_assembly_overrides_contents = { |
| developer_only_options = { |
| forensics_options = { |
| build_type_override = "userdebug" |
| } |
| } |
| } |
| ``` |
| |
| Valid options for `build_type_override` are `user`, `userdebug` and |
| `eng_with_upload`. |
| |
| Note, the above overrides only work for eng builds and product assembly will fail |
| if used on user/userdebug builds. |
| |
| Then, after running each one of the helper programs (see commands in sections |
| below), you should then look each time for the following line in the syslog: |
| |
| ```sh |
| (host)$ ffx log --tag forensics |
| ... |
| Successfully uploaded report at $URL... |
| ... |
| ``` |
| |
| Click on the URL (contact OWNERS 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. |
| |
| ### Unit tests |
| |
| To run the unit and integration tests: |
| |
| ```sh |
| (host) $ fx test //src/developer/forensics |
| ``` |
| |
| ### Root job termination |
| |
| The following command causes the root job to be terminated due to a critical |
| process death: |
| |
| ```sh |
| (host)$ ffx component stop archivist.cm |
| ``` |
| |
| 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: |
| |
| ```sh |
| (target)$ crasher |
| ``` |
| |
| You can immediately look at the syslog. |
| |
| ## Question? Bug? Feature request? |
| |
| Contact OWNERS. |