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)

defect
Not set
normal

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.
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)
Attachment #8336314 - Flags: review?(gps) → review+
Blocks: 941854
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
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]
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.
How can we determine when the last clobber build was done in the sequence of pushes to inbound?
(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.
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 → ---
Whiteboard: [perf_regression] → [talos_regression]
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 ago11 years ago
Resolution: --- → FIXED
Joel did, the log quoted in comment 9 was not a clobber, neither from the releng side, nor the in-tree CLOBBER file.
Depends on: 942920
I filed bug 942920 to track this, we will need to fix this prior to the next uplift.
No longer depends on: 942920
Depends on: 942920
No longer depends on: 942920
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: