Emily: can you take a look? Not sure how this happens since we have unittest for the crash symbolization...

Oh, it looks like the unittest is currently flaky:  issue 633761  :-(

Probably why the test is flaky, there is obviously an issue with it being symbolized correctly.  So maybe the test is failing correctly!  I will investigate further.

So if you look at the link to the logs above: 

https://build.chromium.org/p/chromium.perf/builders/Mac%2010.11%20Perf%20%284%29/builds/3879/steps/v8.browsing_desktop/logs/stdio/text

and the link in  issue 633761  for the flaky test asserting we have stack traces: https://build.chromium.org/p/chromium.mac/builders/Mac10.10%20Tests/builds/7722/steps/telemetry_perf_unittests/logs/stdio

and there is common output right before the stack trace (or lack there of) is dumped out: 

	2016-08-10 05:03:16.235 Google Chrome[12693:100439] NSWindow warning: adding an unknown subview: <FullSizeContentView: 0x7fdf5a7c3640>. Break on NSLog to debug.
	2016-08-10 05:03:16.235 Google Chrome[12693:100439] Call stack:
	(
	    "+callStackSymbols disabled for performance reasons"
	)

Maybe this is completely unrelated as it has to do with chrome, but I thought it was worth investigating.  It could be generated from this file within chrome:  https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/full_size_content_window.mm but I haven't dug through it or tried to understand it enough to know if it is related. 

Either one of two things is going on here which would help in my path to debugging.  Since it is failing similarly on both the perf waterfall and on the chromium waterfall (and by failing I mean failing to produce an accurate stack trace that can be symbolized although they may be failing differently) I have to assume one of two things: 

1) There is something specific to how chrome is interacting with mac and there is a mac setting or issue where it is not producing the stack trace in all cases.  I have cc'd erikchen@ as I was told he was a mac expert.

2) Or there is something that telemetry is not aware of with regards to mac and the actual telemetry code is inaccurately trying to obtain the stack traces.  

If #1 reproducing the error on a mac and trying to understand the mac infrastructure might help me debug this easier and with #2 it might be easier to look at the telemetry code and try gathering more information on the unittest failures.  This could go back to adding more utilities besides screenshots to obtain system data at the time of crash.

eyaich: The console logs you quoted 
"""
	2016-08-10 05:03:16.235 Google Chrome[12693:100439] NSWindow warning: adding an unknown subview: <FullSizeContentView: 0x7fdf5a7c3640>. Break on NSLog to debug.
	2016-08-10 05:03:16.235 Google Chrome[12693:100439] Call stack:
	(
	    "+callStackSymbols disabled for performance reasons"
	)
"""

are not relevant. I'm not familiar with how Telemetry emits stack traces during a crash, nor the symbolication process. I would recommend building a custom version of Chrome locally that crashes shortly after startup, and then testing locally to see if you can get symbolicated crashes.

Is that issue becoming irrelevant as per migration to swarming (issue 633253) ?

Marc: that's a good point. Though it's unsure whether the Chrome build config of perf benchmark will be the same as ones we use for unittest.