-
mark authored
When Crashpad self-monitoring is enabled, crashes in crashpad_handler will be written to the crash report database and uploaded according to the user's preference. Self-monitoring dedicates an additional crashpad_handler process to serve as the handler for the original instance. Having a dedicated process is somewhat expensive, so self-monitoring is not enabled at all times. An existing mechanism, the "fallback crash handler," is already in place on Windows. The fallback crash handler does not create any additional processes until a crashpad_handler crash occurs. The fallback handler remains effective in cases where Crashpad's own self-monitoring is disabled. The fallback handler and Crashpad self-monitoring have different attributes, so there are no plans to move Windows entirely onto Crashpad self-monitoring. For branded Chrome, the dev channel gets Crashpad self-monitoring in 25% of browser starts, and the beta channel gets it in 10% of browser starts. On macOS, the stable channel gets self-monitoring in 1% of browser starts, and the canary and Chromium builds get it all the time. On Windows, the Chrome stable channel never gets self-monitoring because the fallback crash handler is sufficient, and the canary and Chromium builds get it 50% of the time, allowing for some use of the fallback crash handler in those cases. While reports will be collected for crashes that occur while Crashpad is attempting to upload another report, it's unlikley that these reports will be uploaded automatically under the current one-attempt-per-hour, no-retry rate limiting strategy. See https://crashpad.chromium.org/bug/23. BUG=crashpad:143 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng Review-Url: https://codereview.chromium.org/2799013002 Cr-Commit-Position: refs/heads/master@{#463352}
dde55ab7