Allow a tad more race-induced histogram errors

When the sum of the buckets is "significantly" different from a second counter, which is incremented when any bucket is bumped, then we declare the histogram to be potentially "spammed."  The limit was a difference by 1, but examination of the UMA uploads shows that for some histograms, this can grow larger.  This CL increases the threshold from "as much as 1 away" to "as much as 5 away."

r=rtenneti

Review URL: https://chromiumcodereview.appspot.com/10833026

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@148997 0039d316-1c4b-4281-b951-d872f2087c98

base/metrics/histogram.cc

@@ -363,7 +363,7 @@ Histogram::Inconsistencies Histogram::FindCorruption(
     // UMA in about a half hour, so we'll eventually get the data, if it was
     // not the result of a corruption.  If histograms show that 1 is "too tight"
     // then we may try to use 2 or 3 for this slop value.
-    const int kCommonRaceBasedCountMismatch = 1;
+    const int kCommonRaceBasedCountMismatch = 5;
     if (delta > 0) {
       UMA_HISTOGRAM_COUNTS("Histogram.InconsistentCountHigh", delta);
       if (delta > kCommonRaceBasedCountMismatch)