New issue
Advanced search Search tips

Issue 865357 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Closed: Aug 27
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-08-25
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

[Android WebView] Lower minidump crash reporting fraction in time for 69 Stable

Project Member Reported by tobiasjs@chromium.org, Jul 19

Issue description

We did this for 68 in crbug.com/845111

1% remains the right fraction, although we might want to consider 2% in case crashpad is not going to support microdumps. 

This might also be obsoleted by the availability of finch.
 
Cc: benmason@chromium.org
Any updates on this? M69 stable is fast approaching.
No word on doing this via finch, yet. Cherrypick of the reduction CL should happen at the end of this week (25th), so that we still get full crash volume from the last beta.
NextAction: 2018-08-25
The NextAction date has arrived: 2018-08-25
tobiasjs@ the beta this week is expected to be the release candidate, so it would be good for whatever changes are needed here to be landed ASAP.
Project Member

Comment 7 by bugdroid1@chromium.org, Aug 27

Labels: merge-merged-3497
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5b05e979e53040a042a3c0e8604a5dbdb089eadc

commit 5b05e979e53040a042a3c0e8604a5dbdb089eadc
Author: Tobias Sargeant <tobiasjs@google.com>
Date: Mon Aug 27 14:06:38 2018

[Android WebView] Lower minidump generation fraction to 1% for Stable

To avoid hitting the cap on the number of uploaded crash reports per day
we lower the fraction of uploaded reports from 100% for Beta to 1% for
Stable.
Note that there should be at least one Beta version with the new lowered
fraction since we do not want to re-push Beta just for this change.

TBR: torne@chromium.org
Bug:  865357 
Change-Id: I7dfe6fbf73e64488a50755f0bf41a9e6f303dcfe
Reviewed-on: https://chromium-review.googlesource.com/1190344
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#810}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/5b05e979e53040a042a3c0e8604a5dbdb089eadc/android_webview/common/crash_reporter/aw_crash_reporter_client.cc

Labels: CommitLog-Audit-Violation Merge-Without-Approval
Here's a summary of the rules that were executed: 
 - OnlyMergeApprovedChange: Rule Failed -- Revision 5b05e979e53040a042a3c0e8604a5dbdb089eadc was merged to refs/branch-heads/3497 branch with no merge approval from a TPM! 
Please explain why this change was merged to the branch!
Lazily chose to upload a WIP CL on master and use the Gerrit interface to cherry pick to m69 rather than just land the commit directly on the branch. Sorry about the unintentional noise that appears to have caused.
Status: Fixed (was: Assigned)
Closing this out as it has been merged.
Labels: -CommitLog-Audit-Violation -Merge-Without-Approval
Removing merge violation labels.
Status: Verified (was: Fixed)
Marking verified on webview : 69.0.3497.69 / Stable,
As minidump are not uploading as per the fix.

Device: Pixel XL/O

Hmm.. Why do we roll this change every milestone? Can we land this in ToT for now?
We want the crash reporting rate to be 100% for dev/beta builds, so it must never be landed in ToT.

Sign in to add a comment