SeaMonkey Windows nightly builds fail in content/base/test because command line is too long (32k char limit)

RESOLVED FIXED in mozilla21

Status

()

Core
DOM
--
major
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: mcsmurf, Assigned: mcsmurf)

Tracking

Trunk
mozilla21
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
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

6 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.
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

6 years ago
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)
(Assignee)

Updated

6 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 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

6 years ago
Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/8507903e43cb
OS: Windows 7 → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla21

Comment 7

6 years ago
https://hg.mozilla.org/mozilla-central/rev/2bf4d2e75011
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"
Keywords: verifyme
OS: All → Windows 7
Hardware: All → x86
(Assignee)

Comment 9

6 years ago
Windows builds look fine again and are up-to-date.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.