So looking at this more, the task is the one that's posted by InternalPostTask - so actually it's not the histogram synchronizer code itself but whatever callback is given to it.

So let's trace back where it's coming from:

InternalPostTask
SetTaskRunnerAndCallback
HistogramSynchronizer::FetchHistogramsAsynchronously
content::FetchHistogramsAsynchronously
ChromeMetricsServiceClient::OnMemoryDetailCollectionDone
ChromeMetricsServiceClient::OnHistogramSynchronizationDone
ChromeMetricsServiceClient::CollectFinalMetricsForLog

->
MetricsService::OnFinalLogInfoCollectionDone

So that's the culprit I think.

So interestingly, this *can* call OpenNewLog(). So I think this is likely the same issue that Etienne was seeing in another trace. (Not 100% sure because it's not clear that OpenNewLog() inside MetricsService::OnFinalLogInfoCollectionDone is to blame or something else.)

.... I think stack sampled metrics would be a good use here rather than trying to reason about all of this manually. Etienne, is that something you're already collaborating on Mike with? Or when you mentioned stacks was that something else?

FYI This is what OnFinalLogInfoCollectionDone looks like in sampling profiler data:

https://uma.googleplex.com/callstacks?sid=891c3560dbe29e34891ad81bf240442c

Nothing stands out very obviously.

(Also I appreciate if someone can double check my callback following logic in comment 2 to make sure I didn't miss something.)

I personally use the UMA sampler to understand the calltree. It ease debugging a lot.

We are rolling out a version of slow-reports that is running the sampler profiler. It will ease the correlation of both. Some results should come in a few days.

Keep in mind that the UMA sampler profile is the "average" user, but the slow-reports is the 99th percentile user. We won't see the same profile and often some rare codepaths may be executed.