Sounds similar to what was hit in bug 1019955 and a result of scache. Something in this push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startID=46604&endID=46605 https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=b489ff052163 Resulted in: https://tbpl.mozilla.org/php/getParsedLog.php?id=44356812&tree=Mozilla-Inbound { make[5]: Entering directory `/builds/slave/m-in-lx-d-00000000000000000000/build/obj-firefox/image/decoders/icon/gtk' make[5]: Nothing to be done for `export'. make[5]: Leaving directory `/builds/slave/m-in-lx-d-00000000000000000000/build/obj-firefox/image/decoders/icon/gtk' Traceback (most recent call last): File "/builds/slave/m-in-lx-d-00000000000000000000/build/dom/bindings/GenerateCSS2PropertiesWebIDL.py", line 8, in <module> propList = eval(sys.stdin.read()) File "<string>", line 1 Start server ^ SyntaxError: invalid syntax make[5]: *** [CSS2Properties.webidl] Error 1 make[5]: *** Deleting file `CSS2Properties.webidl' make[5]: Leaving directory `/builds/slave/m-in-lx-d-00000000000000000000/build/obj-firefox/dom/bindings' make[4]: *** [dom/bindings/export] Error 2 make[4]: *** Waiting for unfinished jobs... }

Mike, would you mind taking a look - given this seems like it's a result of scache?

FWIW: I'm guessing this was triggered by my (minimal) tweak to nsCSSPropList.h, in this cset: https://hg.mozilla.org/integration/mozilla-inbound/rev/5988d4a17c59 since that .h file is our source-of-truth for what properties exist. (I don't actually know how GenerateCSS2PropertiesWebIDL.py works, but I'll bet it uses that file.)

Since the "Start server" string caused other issues as well (like bug 1019955), we should probably just remove it, or at least print it to stderr as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=1019955#c14

Hit this bug this evening, touched CLOBBER to fix: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=3928403b6627

If it happens again, please do *not* solve it with a CLOBBER update, because it only affects automation, no need to have everyone clobber.

(In reply to Mike Hommey [:glandium] from comment #5) > If it happens again, please do *not* solve it with a CLOBBER update, because > it only affects automation, no need to have everyone clobber. Not using the CLOBBER file isn't practical, since manually clobbering automation machines (say all trees at once) doesn't help when the change merges to other trees (trees that have since re-built builds on old csets since the mass-clobber). In-lieu of an automation-only CLOBBER file (I've added this to bug 1043262), we should just set a CLOBBER file message of "Automation-only clobber, please override locally" etc.

Merges are less likely to trigger this.