I'm guessing Pawel would know best what's going on here, but adding some others.

This might be the same as  bug 511456 , namely that we're not including .pdb's in the isolates in all cases, but there might be something else going on as well.

I don't think this is a recipe thing per se.

Ah, if this is related to GYP->GN switch on trybots, it seems like a major regression. We've had many problems in the past when symbols weren't sent to swarming bots, so we need that to keep working.

https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/247599/steps/telemetry_perf_unittests%20%28with%20patch%29%20on%20Windows-7-SP1/logs/stdio is passing the stacktrace_unittest tests, which symbolize minidumps, so at least some isolates contain pdbs.

I looked at the trigger step for unit_tests, found the "data:" for the Swarming server, and downloaded the isolate via:

./tools/swarming_client/isolateserver.py download -t foo -s c84f716b23304cf4e27aef5448e5b0aded2205be -I https://isolateserver.appspot.com

The directory structure doesn't contain any PDBs.

With GN it should be possible to automatically include PDBs for the built DLLs in isolates, correct? We could verify that the test launcher can symbolize stacks by sending tryjobs with deliberate crashes, once the PDBs are being included.

"nearly automatically" is probably more accurate.

I can work on a fix for this shortly. 

Okay, I worked on a fix and it turns out that we can't quite get what we want out of GN for this today. So, I'm punting this to brettw@ to work on this while I go back to working on analyze.

 Issue 511456  has been merged into this issue.

We need to fix this (or some near variant, at least) in order to get the win installer working, because it wants to include nacl64.pdb and there's no good way to reference that file at the moment because GN doesn't know it exists.

 Issue 630343  has been merged into this issue.

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

commit f79ed9d194a29309f5e6e9a680295459114cbfe4
Author: dpranke <dpranke@chromium.org>
Date: Wed Jul 27 23:59:19 2016

Make sure PDB files are in runtime_deps for GN builds.

Before r407890, we had no good way to make sure that
we were including the .pdb files for executables and
shared libraries in the runtime_deps for a target.
Now that GN has a `runtime_outputs` option, we can
use that and list the PDBs. This should fix issues
for debugging and also packaging the NaCl files as
part of an official build.

R=brettw@chromium.org, sebmarchand@chromium.org
BUG= 624478 , 629709

Review-Url: https://codereview.chromium.org/2192643002
Cr-Commit-Position: refs/heads/master@{#408282}

[modify] https://crrev.com/f79ed9d194a29309f5e6e9a680295459114cbfe4/build/toolchain/win/BUILD.gn
[modify] https://crrev.com/f79ed9d194a29309f5e6e9a680295459114cbfe4/components/nacl/broker/BUILD.gn

I think this is probably fixed now. Anyone happen to have a test case we can use to verify this?

+Emily who is owning this part of telemetry

src/tools/perf/core/stacktrace_unittest.py attempts to verify symbolization of stack traces, and consequently the presence of PDB files.

testCrashMinimalSymbols in that file is already enabled on Windows, so I'm not sure why it would have been working before, if the PDBs were really absent.

It would be ideal to enable testCrashSymbols in that file. I'm not sure, however, whether it can be. I recall that David Yen tried enabling it on Windows once, but surprisingly, on some of the bots, the (DLL-exported) CrashIntentionally function wasn't in the stack trace -- perhaps inlined into a caller.