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.
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.
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.
Created attachment 712369 [details] [diff] [review] Patch 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: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #712369 - Flags: review?(ted)
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 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+
OS: Windows 7 → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla21
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)
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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"
OS: All → Windows 7
Hardware: All → x86
Windows builds look fine again and are up-to-date.
You need to log in before you can comment on or make changes to this bug.