941824 - Add a way to protect ourselves from known bad patterns in unified builds

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[(no longer active)]

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 1

[(no longer active)]

Attachment: #define MOZ_UNIFIED_BUILD for everything that is compiled in unified mode; r=gps

Comment 2

[(no longer active)]

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! :)

Comment 3

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6ea48618123c

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6ea48618123c

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

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?

Comment 6

[Mike Hommey [:glandium]]

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

[Joel Maher ( :jmaher ) (UTC -8)]

How can we determine when the last clobber build was done in the sequence of pushes to inbound?

Comment 8

[(no longer active)]

(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

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 10

[(no longer active)]

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.

Comment 11

[Ed Morley [:emorley]]

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

[Joel Maher ( :jmaher ) (UTC -8)]

I filed bug 942920 to track this, we will need to fix this prior to the next uplift.