Closed
Bug 839936
Opened 11 years ago
Closed 11 years ago
SeaMonkey Windows nightly builds fail in content/base/test because command line is too long (32k char limit)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla21
People
(Reporter: mcsmurf, Assigned: mcsmurf)
Details
Attachments
(1 file)
2.28 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
The current comm-central Windows nightly builds fail with the error /bin/sh: e:/builds/slave/c-cen-t-w32-ntly/build/objdir/mozilla/_virtualenv/Scripts/python.exe: Bad file number This is similar to Bug 829481, we probably need to shorten the objdir even more for nightly builds (except if another bug fix comes up). Current trunk build objdir on buildslave: e:/builds/slave/c-cen-t-w32/ Current trunk nightly build objdir on b.: e:/builds/slave/c-cen-t-w32-ntly/ 5 chars longer, current length for failing command is 33847 chars (32k char limit is the problem I think). Maybe we can shorten "ntly" to "n", need to check if this is enough.
Assignee | ||
Comment 1•11 years ago
|
||
I did some math: In that command "c-cen-t-w32-ntly" gets used 366 times. So if it's a "real" 32k limit (32*1024), shortening ntly to n should be enough.
Comment 2•11 years ago
|
||
Real fix is to s/two/three/ at http://mxr.mozilla.org/mozilla-central/source/content/base/test/Makefile.in?force=1#37 (and do said change) I'd rather not muck with this dir length as a hack.
Assignee | ||
Comment 3•11 years ago
|
||
This patch splits the command-line up again, in the end FF will benefit from this, too as it would also break one day when the command line gets too long again. I've split it up after 234 entries (so section A and B now contain each 234 test files). It also removes an existing MOCHITEST_FILES_C section and integrates it in the new MOCHITEST_FILES_C section. Ted: I'm not sure if you still do these kind of reviews (you did the review for the last split-up), if not, please tell me who else does those reviews these days. Thanks!
Assignee | ||
Updated•11 years ago
|
Component: Release Engineering → DOM
Product: SeaMonkey → Core
Summary: SeaMonkey Windows nightly builds fail with "python.exe: Bad file number" → SeaMonkey Windows nightly builds fail in content/base/test because command line is too long (32k char limit)
Comment 4•11 years ago
|
||
Comment on attachment 712369 [details] [diff] [review] Patch Review of attachment 712369 [details] [diff] [review]: ----------------------------------------------------------------- We really need to work out a better solution here, but this is fine for now.
Attachment #712369 -
Flags: review?(ted) → review+
Assignee | ||
Comment 5•11 years ago
|
||
Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/8507903e43cb
OS: Windows 7 → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla21
Assignee | ||
Comment 6•11 years ago
|
||
Backed out and relanded because of wrong bug #: https://hg.mozilla.org/integration/mozilla-inbound/rev/2bf4d2e75011 (patch) https://hg.mozilla.org/integration/mozilla-inbound/rev/9b06c6b2b2b0 (backout)
Comment 7•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2bf4d2e75011
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 8•11 years ago
|
||
I notice that Windows builders have turned back to green (except the nightly, whose latest build was before comment #7) so I would VERIFY this bug, except that I'm on Linux. Any Windows user interested? Hourly builds (one subdirectory per build): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-central-trunk-win32/?C=M;O=D Nightly builds (once the next nightly will be built): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/?C=M;O=D (use the win32 build, and check the build date before downloading) The ?C=M;O=D query string at the end means "sort the FTP directory latest-first"
Keywords: verifyme
Updated•11 years ago
|
OS: All → Windows 7
Hardware: All → x86
Assignee | ||
Comment 9•11 years ago
|
||
Windows builds look fine again and are up-to-date.
Keywords: verifyme
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•