I will take a look shortly.

Do you have a link to the failed test?

https://uberchromegw.corp.google.com/i/internal.bling.main/builders/smoke/builds/22156/steps/base_unittests%20%28iPhone%205s%20iOS%2010.0%29%20on%20Mac

https://uberchromegw.corp.google.com/i/internal.bling.main/builders/smoke/builds/22155/steps/base_unittests%20%28iPhone%205s%20iOS%2010.0%29%20on%20Mac

https://uberchromegw.corp.google.com/i/internal.bling.main/builders/smoke/builds/22154/steps/base_unittests%20%28iPhone%205s%20iOS%2010.0%29%20on%20Mac

And basically all the run of base_unittests on iOS.
This also reproduce locally.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bbc796ad6bfca187b3b1f686950212a38683fa66

commit bbc796ad6bfca187b3b1f686950212a38683fa66
Author: Xi Cheng <chengx@chromium.org>
Date: Fri Apr 27 18:38:38 2018

Disable persistent_histogram_storage_unittest on IOS

This test fails on OS_IOS as mentioned in the bug below. So disable it to
unblock any related work. This is fine as PersistentHistogramStorage is
used only on OS_WIN now.

Bug: 836789
Change-Id: I4e86cf4053663d4736cb3242ffaf22c0a1030781
Reviewed-on: https://chromium-review.googlesource.com/1033016
Reviewed-by: Brian White <bcwhite@chromium.org>
Commit-Queue: Xi Cheng <chengx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554429}
[modify] https://crrev.com/bbc796ad6bfca187b3b1f686950212a38683fa66/base/metrics/persistent_histogram_storage_unittest.cc

If the failure is:


void HistogramBase::CheckName(const StringPiece& name) const {
  DCHECK_EQ(StringPiece(histogram_name()), name);
}


This means that there's some histogram macro (e.g. UMA_HISTOGRAM_ENUMERATION()) which is being called with the first string param that's different between two invocations. The requirement for correct functionality is the name parameter is constant because the macro caches the Histogram object locally and later invocations of the same macro will log to that cached object. When it's called with a different name, this DCHECK is triggered. (In production, this would mean a sample for a metric A might be logged for metric B.)

So the real fix is figuring out which histogram is being logged in this buggy way and fix the way they use the histograms API. Presumably if we know where it's failing, we have the full stack trace and can find the call site in question.

Thanks asvitkine@.

The trace in the link above (comment 3) has vague connection with the PersistentHistogramStorageTest code I added. I am swamped by other things now so I will come back later. It is hard for me to test as this is IOS though.

I will note that, even though this is technically a test failure, it likely indicates bad data will appear in logs produced by production code.

If you don't plan to look into it, perhaps you should assign it to someone on the iOS team to do so.

Re comment 7:

AFAICT, the test failure only exists in IOS, while the PersistentHistogramStorage class is used on Windows only. In terms of production code that produces that bad code, do you mean code in OS_WIN or in OS_IOS?

On iOs. If the failure occurs on iOS, then it's likely something that's it's calling deeper in the stack records a problematic histogram.  This may be entirely independent of persistent histograms; it's just persistent histograms have enough checks to warn about the situation.

@olivierrobin

Since the test is disabled on ios, the ios buildbots should be happy now. However, as suggested by mpearson@, this test failure likely indicates some issues in ios production code. If you could find someone on ios team to take a look, that would be great.

Marking this bug available.