Closed Bug 794490 Opened 7 years ago Closed 6 years ago
When Windows builds fail, sometimes pymake returns -127 and no compiler output is seen
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.
Attachment #665414 - Flags: review?(ted.mielczarek) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Still fails: https://tbpl.mozilla.org/?tree=Try&rev=9f97d7fdf3d6 ekr verified that the pymake in his push has the change.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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  made them show errors properly. 1. http://mxr.mozilla.org/mozilla-central/source/config/config.mk#129
Status: REOPENED → NEW
Target Milestone: mozilla18 → ---
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.
Status: NEW → RESOLVED
Closed: 7 years ago → 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 799189
You need to log in before you can comment on or make changes to this bug.