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

Categories

(Firefox Build System :: General, defect)

x86
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 799189

People

(Reporter: jesup, Assigned: glandium)

References

()

Details

Attachments

(1 file)

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.
(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).
Assignee: nobody → mh+mozilla
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+
https://hg.mozilla.org/mozilla-central/rev/dc70ce87180c
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite-
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 [1] 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.
Duplicate of this bug: 800946
Duplicate of this bug: 797351
Blocks: 585011
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 ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 799189
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.