785748 - xul!1.pgc getting packaged in Windows PGO builds

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

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

Comment 2

[(not currently active) Ted Mielczarek]

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.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

(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.

Comment 5

[(not currently active) Ted Mielczarek]

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

Comment 6

[Mike Hommey [:glandium]]

Oh, so this would be fallout from bug 785102

Comment 7

[Justin Wood (:Callek)]

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

Comment 8

[Justin Wood (:Callek)]

(In reply to Mike Hommey [:glandium] from comment #6)
> Oh, so this would be fallout from bug 785102

CC'ing :espindola based on that

Comment 9

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

(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.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 11

[(not currently active) Ted Mielczarek]

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

Comment 12

[Chris AtLee [:catlee]]

Would this affect future updates in any way?

Comment 13

[(not currently active) Ted Mielczarek]

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

Comment 14

[Ryan VanderMeulen [:RyanVM]]

This worked itself out at some point along the way.