Closed
Bug 941824
Opened 11 years ago
Closed 11 years ago
Add a way to protect ourselves from known bad patterns in unified builds
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla28
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
Details
(Keywords: perf, regression, Whiteboard: [talos_regression])
Attachments
(1 file)
The idea is to define a preprocessor macro when in unified mode which we can use to check certain patterns that we know must never occur in unified builds.
Assignee | ||
Comment 1•11 years ago
|
||
Assignee | ||
Comment 2•11 years ago
|
||
Comment on attachment 8336314 [details] [diff] [review]
#define MOZ_UNIFIED_BUILD for everything that is compiled in unified mode; r=gps
Greg, we need this pretty badly, so fast reviews are highly appreciated! :)
Attachment #8336314 -
Flags: review?(gps)
Updated•11 years ago
|
Attachment #8336314 -
Flags: review?(gps) → review+
Assignee | ||
Comment 3•11 years ago
|
||
Comment 4•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Comment 5•11 years ago
|
||
this is causing a regression from talos numbers in modified page list bytes by 27%:
https://groups.google.com/forum/#!topic/mozilla.dev.tree-management/zMyoTUZQgKc
http://graphs.mozilla.org/graph.html#tests=[[271,131,25]]&sel=none&displayrange=7&datatype=running
For reference this is the history of adding this counter: https://bugzilla.mozilla.org/show_bug.cgi?id=558613.
Is this regression desired?
Keywords: perf,
regression
Whiteboard: [perf_regression]
Comment 6•11 years ago
|
||
It's not possible to cause that regression. However, the change caused all unified sources to be rebuilt, which means a partial clobber. It's very likely that the real cause of the regression is something that landed before this patch, required a clobber but didn't get one.
Comment 7•11 years ago
|
||
How can we determine when the last clobber build was done in the sequence of pushes to inbound?
Assignee | ||
Comment 8•11 years ago
|
||
(In reply to comment #7)
> How can we determine when the last clobber build was done in the sequence of
> pushes to inbound?
You can examine each individual build log manually. I don't know if there is an easier way.
Comment 9•11 years ago
|
||
I looked at the build log for this:
https://tbpl.mozilla.org/php/getParsedLog.php?id=30918686&tree=Mozilla-Inbound&full=1
it doesn't appear to be a clobber from looking at the log file. If there is a way to determine that in the log file, please outline it here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•11 years ago
|
Whiteboard: [perf_regression] → [talos_regression]
Assignee | ||
Comment 10•11 years ago
|
||
Not sure why you reopened this bug.
(In reply to Joel Maher (:jmaher) from comment #9)
> I looked at the build log for this:
> https://tbpl.mozilla.org/php/getParsedLog.php?id=30918686&tree=Mozilla-
> Inbound&full=1
>
> it doesn't appear to be a clobber from looking at the log file. If there is
> a way to determine that in the log file, please outline it here.
See the entry marked as "Started checking clobber times" in the log. That code reaches out to a web server giving you a timestamp of the clobberer for the current tree, and we choose whether to clobber based on that. Please ask one of our sheriffs for a more accurate answer, I haven't done this stuff in a while.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Comment 11•11 years ago
|
||
Joel did, the log quoted in comment 9 was not a clobber, neither from the releng side, nor the in-tree CLOBBER file.
Comment 12•11 years ago
|
||
I filed bug 942920 to track this, we will need to fix this prior to the next uplift.
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•