01:15:24 INFO - lld-link.exe: error: could not open z:/build/build/src/obj-firefox/cygprofile.txt: no such file or directory 01:15:24 INFO - z:/build/build/src/config/rules.mk:704: recipe for target 'xul.dll' failed 01:15:24 INFO - mozmake.EXE[5]: *** [xul.dll] Error 1 01:15:24 INFO - mozmake.EXE[5]: Leaving directory 'z:/build/build/src/obj-firefox/toolkit/library' 01:15:24 INFO - z:/build/build/src/config/recurse.mk:74: recipe for target 'toolkit/library/target' failed 01:15:24 INFO - mozmake.EXE[4]: *** [toolkit/library/target] Error 2 01:15:24 INFO - z:/build/build/src/config/recurse.mk:32: recipe for target 'compile' failed 01:15:24 INFO - mozmake.EXE[3]: *** [compile] Error 2 01:15:24 INFO - z:/build/build/src/config/rules.mk:432: recipe for target 'default' failed 01:15:24 INFO - mozmake.EXE[2]: *** [default] Error 2 01:15:24 INFO - Makefile:220: recipe for target 'profiledbuild' failed 01:15:24 INFO - mozmake.EXE[1]: *** [profiledbuild] Error 2 01:15:24 INFO - client.mk:150: recipe for target 'build' failed 01:15:24 INFO - mozmake.EXE: *** [build] Error 2 01:15:24 INFO - 425 compiler warnings present. I suspect that this is due to the presence of the launcher process complicating the PGO profiling run. Would this just be a matter of adding --wait-for-browser to the command line, so that the launcher process (and any scripts that wait on it) wait for the browser to finish running?

I've been meaning to get rid of the cygprofile stuff entirely; last I checked, it no longer gives us any perf now that we have proper PGO enabled. I've held off on doing so just in case some miscompilation comes up on 63 beta and makes us temporarily back out PGO, but now that we're past merge day it should be safe to proceed on 64. I'll want to do one more talos comparison to double-check... If you can't wait and --wait-for-browser does the job, go for it.

After adding some logging, I have determined that the launcher process is stuck in a loop where it is continuously re-launching itself instead of starting the browser. I am unsure as to why this is occurring in automation, but I am adding more logging to determine that.

Note that a local PGO build does *not* end up in the infinite loop.

Interesting. Our parent process binary is reported as: Z:\task_1537286203\build\src\obj-firefox\dist\firefox\firefox.exe but our own binary is reported as: z:\build\build\src\obj-firefox\dist\firefox\firefox.exe These binaries are presumably the same, but the paths are different. Junction point? Drive mapping? Anyway, it sounds like that needs to be resolved somehow.

It's a symlink: https://dxr.mozilla.org/mozilla-central/rev/87a95e1b7ec691bef7b938e722fe1b01cce68664/taskcluster/taskgraph/transforms/job/mozharness.py#331

Moving components since this is a launcher process bug.

Depends on D6340

Comment on attachment 9010472 [details] Bug 1488627: Part 1 - Add FileUniqueId and DoPathsPointToIdenticalFile to WinHeaderOnlyUtils.h; r=mhowell! Matt Howell [:mhowell] has approved the revision.

Comment on attachment 9010473 [details] Bug 1488627: Part 2 - Use file IDs instead of paths in launcher process parent binary check; r=mhowell! Matt Howell [:mhowell] has approved the revision.

Pushed by aklotz@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/baa0f84b80b2 Part 1 - Add FileUniqueId and DoPathsPointToIdenticalFile to WinHeaderOnlyUtils.h; r=mhowell https://hg.mozilla.org/integration/autoland/rev/37cd7bbec974 Part 2 - Use file IDs instead of paths in launcher process parent binary check; r=mhowell

https://hg.mozilla.org/mozilla-central/rev/baa0f84b80b2 https://hg.mozilla.org/mozilla-central/rev/37cd7bbec974