Possibly the same or related to bug 787658 When building with pymake, fairly often when a compile fails on windows you see "return code -127" and see no compiler output. See the URL for an example. It's often quite repeatable for a particular failure; I did 5 runs on my local machine hitting it last weekend to see if it was flakey; all failed.

I meant to file this, but I totally forgot. glandium said he thought it was a race condition between the output being buffered and the process exit.

A previous example on alder: https://tbpl.mozilla.org/php/getParsedLog.php?id=15293672&tree=Alder the same failure on Win64 with the error output: https://tbpl.mozilla.org/php/getParsedLog.php?id=15293711&tree=Alder

(In reply to Ted Mielczarek [:ted] from comment #1) > I meant to file this, but I totally forgot. glandium said he thought it was > a race condition between the output being buffered and the process exit. I was mentioning something else, but that could certainly be the same root problem. We really need to unbuffer stdout and stderr. The two solutions to the same kind of problem in bug 483100 was either 1) stick -u in the hash-bang line at the top of the file 2) sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0) (goofy reopening of stdout) In the case of pymake, unless we re-execute python, only the latter would work (while the former was used for bug 483100).

That should be inside the if name == '__main__' section.

Comment on attachment 665414 [details] [diff] [review] Don't buffer stdout and stderr in pymake Review of attachment 665414 [details] [diff] [review]: ----------------------------------------------------------------- r=me with Sid's suggestion.

Still fails: https://tbpl.mozilla.org/?tree=Try&rev=9f97d7fdf3d6 ekr verified that the pymake in his push has the change.

A likely culprit is http://mxr.mozilla.org/mozilla-central/source/build/cl.py#26 I had a try build systematically not showing errors, and removing the cl.py wrapping [1] made them show errors properly. 1. http://mxr.mozilla.org/mozilla-central/source/config/config.mk#129

Hm, quite possibly.

I filed bug 799189 for cl.py foo. I just realized this was reopened. It's been a long week.

I just backed bug 585011 out, so this shouldn't be an issue on tinderboxes any more.

Can we move forward on this? Just got another confused dev hitting it (or some variant) in bug 814619

With the backout of bug 585011 this shouldn't be an issue.

Between comment 17 and bug 799189 switching cl.py to use mozprocess, I'm pretty sure this is not an issue and never will be.