Just noticed this the other day on my own personal builds. I was able to confirm that tinderbox builds are showing the same thing. Downloading m-c PGO zips gives me a regression range of: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22288130fea2&tochange=d9183f015df8 Thankfully, inbound PGO zips seem to agree on the range: GOOD: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/1344906114/firefox-17.0a1.en-US.win32.zip BAD: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/1344916898/firefox-17.0a1.en-US.win32.txt http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4b26b044d57d&tochange=d1306b8d3242 Thing is, nothing in that range looks likely.

Try builds to hopefully confirm the regression range. 4b26b044d57d - https://tbpl.mozilla.org/?tree=Try&rev=555725ef6b47 d1306b8d3242 - https://tbpl.mozilla.org/?tree=Try&rev=8ab806209534

This is worrisome, because the pgc files are supposed to be removed after they're merged into the pgd file. If they're not being merged, then the profiling data isn't actually being used.

From my local build, it appears that the packaged zip file contains xul!1.pgc after the *first* pass (before profiling). After profiling, the new xul!1.pgc and xul!2.pgc files in dist/bin are merged OK to the pgd. If I left the original zip in dist before running make package, the pgc file is still there in the new one. If I delete the old zip file before running make package, the new zip does not contain it.

(In reply to Ryan VanderMeulen from comment #1) > Try builds to hopefully confirm the regression range. > > 4b26b044d57d - https://tbpl.mozilla.org/?tree=Try&rev=555725ef6b47 > d1306b8d3242 - https://tbpl.mozilla.org/?tree=Try&rev=8ab806209534 Confirmed.

Oh! This is probably from running xpcshell as part of packaging to populate startupcache, then.

Oh, so this would be fallout from bug 785102

Nomming for tracking based on c#26 in Bug 783784 I think this is indeed [part of what is] causing the l10n windows repacks to fail

(In reply to Mike Hommey [:glandium] from comment #6) > Oh, so this would be fallout from bug 785102 CC'ing :espindola based on that

(In reply to Mike Hommey [:glandium] from comment #6) > Oh, so this would be fallout from bug 785102 Is it? For windows we use RUN_FROM_PWD = $(_ABS_RUN_TEST_PROGRAM) which is what was there in the first place.

Rafael - have you had a chance to look into this? Not sure if we need to track this for 17 - how would this block us from releasing?

This is harmless, we'd just be shipping an extraneous file that has no impact on anything.

Would this affect future updates in any way?

This file is completely ignored by Firefox, so it doesn't matter one whit if it gets removed or corrupted or overwritten .

This worked itself out at some point along the way.