Closed
Bug 1181040
Opened 9 years ago
Closed 9 years ago
Can no longer do Aurora Win64 PGO builds on Try
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(firefox42 fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox42 | --- | fixed |
People
(Reporter: jandem, Assigned: glandium)
References
Details
Attachments
(3 files)
(deleted),
patch
|
mshal
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
gps
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
gps
:
review+
|
Details | Diff | Splinter Review |
I need to debug a PGO-only Win64 issue, see bug 1180948 and bug 1167883. The former is keeping Aurora closed, so this is pretty urgent.
Unfortunately all PGO builds I do are timing out on Try:
Try push from yesterday:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ebd81d3a3722
Try push from last month:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=38a8b8a65b32
Reporter | ||
Updated•9 years ago
|
Severity: normal → blocker
Comment 1•9 years ago
|
||
I've been looking at this today - no leads just yet. The timeouts for try look to be the same as for mozilla-central, so something is causing this to take a lot longer to build than nightlies on trunk.
Comment 2•9 years ago
|
||
Disabling sccache seems to have fixed this for me:
https://hg.mozilla.org/try/rev/fa7efed1756d#l2.17
glandium, any ideas why?
Flags: needinfo?(mh+mozilla)
Assignee | ||
Comment 3•9 years ago
|
||
As I said on irc, this might be due to the difference in how debug symbols are treated with sccache enabled. That's not a problem on non-try because MOZ_PGO is set before mozconfig.cache is included, and mozconfig.cache disables sccache when MOZ_PGO is set.
Flags: needinfo?(mh+mozilla)
Comment 4•9 years ago
|
||
Why would having sccache enabled make PGO builds so much slower? In particular, the 2nd link of xul.dll is taking more than 2x as long.
Flags: needinfo?(mh+mozilla)
Assignee | ||
Comment 6•9 years ago
|
||
Anyways, the reasonable thing to do would be to ensure mozconfig.cache is included last (or at least after mozconfig.common.override) instead of wherever it's included now.
Comment 7•9 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #6)
> Anyways, the reasonable thing to do would be to ensure mozconfig.cache is
> included last (or at least after mozconfig.common.override) instead of
> wherever it's included now.
great - can you get a patch up for that?
Assignee | ||
Comment 8•9 years ago
|
||
Assignee: nobody → mh+mozilla
Attachment #8632009 -
Flags: review?(mshal)
Updated•9 years ago
|
Attachment #8632009 -
Flags: review?(mshal) → review+
Comment 10•9 years ago
|
||
Assignee | ||
Comment 11•9 years ago
|
||
It wasn't enough. sccache doesn't get disabled because mk_add_options doesn't have an effect on local variables in mozconfig, so the tests in mozconfig.cache don't work.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 12•9 years ago
|
||
It is useful to be able, during mozconfig execution, to do tests depending
on what was previously added with mk_add_options. Specifically, there is a
need to do this for MOZ_PGO because developers pushing to try may add it to
mozconfig.common.override.
While, ideally, it would be nice if we just defined the variable itself in
the mozconfig execution environment, that is a tedious task, having to jump
through hoops with eval, and handle all cases of variable assigment properly.
The hacky alternative is to just treat MOZ_PGO specially, but meh.
So instead, we set a ${var}_IS_SET variable to 1, indicating that a
mk_add_options defined ${var} to some value.
Attachment #8644180 -
Flags: review?(gps)
Assignee | ||
Comment 13•9 years ago
|
||
Attachment #8644181 -
Flags: review?(gps)
Comment 14•9 years ago
|
||
Comment on attachment 8644180 [details] [diff] [review]
Set ${var}_IS_SET variables for mk_add_options-defined variables
Review of attachment 8644180 [details] [diff] [review]:
-----------------------------------------------------------------
I'm not a huge fan of adding more complexity to mozconfig evaluation. But I don't have a better idea that is just as simple as this.
Attachment #8644180 -
Flags: review?(gps) → review+
Updated•9 years ago
|
Attachment #8644181 -
Flags: review?(gps) → review+
Comment 15•9 years ago
|
||
Comment 16•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/06de69c7ea12
https://hg.mozilla.org/mozilla-central/rev/c24075996e1d
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•