Closed
Bug 492228
Opened 15 years ago
Closed 14 years ago
[1.9.1] "random" |EXCEPTION: ReferenceError: gAutoconfVars is not defined|
Categories
(Testing :: Reftest, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sgautherie, Assigned: sgautherie)
References
()
Details
(Keywords: intermittent-failure, Whiteboard: [fixed1.9.1.9] )
Attachments
(1 file, 1 obsolete file)
1.33 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
{ http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1241902785.1241910813.3688.gz WINNT 5.2 comm-central unit test on 2009/05/09 13:59:45 REFTEST INFO | runreftest.py | Running tests: start. INFO | (automation.py) | Application pid: 4092 ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to c:\docume~1\seabld\locals~1\temp\1\tmpglqhsf\runreftest_leaks.log REFTEST TEST-UNEXPECTED-FAIL | | EXCEPTION: ReferenceError: gAutoconfVars is not defined REFTEST FINISHED: Slowest test took 0ms (undefined) } { [kairo@kairo.at - 2009/05/09 16:25:16] Not sure why and where it comes from, but this seems to be a common error on fresh build slaves of all platforms (others had it before being switched to SeaMonkey-Ports). Goes away on further cycles from the same machine. } Bug 420084 removed the involved code, but it's not going to land on 1.9.1 :-|
Assignee | ||
Updated•15 years ago
|
Assignee | ||
Comment 1•15 years ago
|
||
(In reply to comment #0) > build slaves of all platforms > (others had it before being > switched to SeaMonkey-Ports). Simply confirming this: { http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243629373.1243636856.15225.gz Linux comm-central unit test on 2009/05/29 13:36:13 }
OS: Windows Server 2003 → All
Assignee | ||
Comment 2•15 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1247222100.1247232546.19688.gz WINNT 5.2 comm-1.9.1 unit test on 2009/07/10 03:35:00
Assignee | ||
Comment 3•15 years ago
|
||
I had never had this error on my local Windows 2000, afair. Today, I tried twice to (clobber) build (optimized) Firefox 3.5 [which I seldom do], and I'm getting the error. This is (now) major because it prevents me from verifying that reftests/crashtests work/pass :-/ (which is precisely what I wanted to do for bug 483062.) I'd love to figure out what is going on! From what I checked, the autoconf.js file is in reftest.jar and contains the gAutoconfVars var definition as expected. I have no clue about what would be causing this error. David, any idea? NB: Next time I see it on a tinderbox, I'll try to download the build and compare it with a working one... (It happens regularly on SeaMonkey 2.0 boxes...) Until then, I'll save my local build so I can further test with them if need be.
Assignee | ||
Comment 4•15 years ago
|
||
(In reply to comment #3) > From what I checked, the autoconf.js file is in reftest.jar and contains the > gAutoconfVars var definition as expected. That was not entirely exact :-< I don't know why it happens, but I found what is wrong with autoconf.js: My 2 local Windows Firefox 3.5 builds: *objdir/layout/tools/reftest: 12 KB, content is right :-) *objdir/_tests/reftest/reftest/chrome/reftest.jar/content: 22 B, "var gAutoconfVars = {\n" only :-( > Next time I see it on a tinderbox, I'll try to download the build and compare > it with a working one... (It happens regularly on SeaMonkey 2.0 boxes...) It just happened :-> http://tinderbox.mozilla.org/showlog.cgi?tree=SeaMonkey2.0&errorparser=unittest&logfile=1251413374.1251421824.19742.gz&buildtime=1251413374&buildname=WINNT%205.2%20comm-1.9.1%20unit%20test&fulltext=1 WINNT 5.2 comm-1.9.1 unit test on 2009/08/27 15:49:34 *log: seems normal (autoconf.js: all lines and no error). *reftest.jar: 12 KB, but misses ending "};\n" line :-( http://tinderbox.mozilla.org/showlog.cgi?tree=SeaMonkey2.0&errorparser=unittest&logfile=1251416767.1251423861.10512.gz&buildtime=1251416767&buildname=WINNT%205.2%20comm-1.9.1%20unit%20test&fulltext=1 WINNT 5.2 comm-1.9.1 unit test on 2009/08/27 16:46:07 *log: seems normal (autoconf.js: all lines and no error). *reftest.jar: 22 B, "var gAutoconfVars = {\n" only :-( http://tinderbox.mozilla.org/showlog.cgi?tree=SeaMonkey2.0&errorparser=unittest&logfile=1251420427.1251426530.9754.gz&buildtime=1251420427&buildname=Linux%20comm-1.9.1%20unit%20test&fulltext=1 Linux comm-1.9.1 unit test on 2009/08/27 17:47:07 *log: seems normal (autoconf.js: all lines and no error). *reftest.jar: 15 KB, but misses ending "};\n" line :-( There is obviously something going wrong when adding autoconf.js to reftest.jar :-(
Whiteboard: [orange] → [See comments 0 & 4] [orange]
Assignee | ||
Comment 5•15 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1252022081.1252031669.17345.gz WINNT 5.2 comm-1.9.1 unit test on 2009/09/03 16:54:41
Assignee | ||
Comment 6•15 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1260156570.1260167528.31236.gz WINNT 5.2 comm-1.9.1 unit test on 2009/12/06 19:29:30
Does this happen only with make -j or -jN ? If so, maybe the build step that puts the file in the jar is running in parallel with the generation of the file?
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #7) That may be the cause: I just noticed that, for 'unittest' builds, SM 2.0 uses |mk_add_options MOZ_MAKE_FLAGS="-j3"|, whereas FF 3.5 doesn't use this option. Would it be possible to make this building task "not parallel"?
Assignee | ||
Updated•14 years ago
|
Whiteboard: [See comments 0 & 4] [orange] → [See comments 0 & 4 & 8] [orange]
Comment 9•14 years ago
|
||
(In reply to comment #8) > (In reply to comment #7) > > That may be the cause: > I just noticed that, for 'unittest' builds, > SM 2.0 uses |mk_add_options MOZ_MAKE_FLAGS="-j3"|, > whereas FF 3.5 doesn't use this option. > > Would it be possible to make this building task "not parallel"? That might help debug the problem, but if it's the cause, wouldn't help in getting a real issue fixed (esp. as more and more developers ware compiling with parallel building options. Also, it would probably slow things down, which is not really helpful in our resource-strained situation.
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #9) > > Would it be possible to make this building task "not parallel"? I wasn't clear enough: I meant to "work around" '-j' for the file generation task... (Not to drop '-j3' from SeaMonkey build. Of course, we agree what that would do.)
Assignee | ||
Comment 11•14 years ago
|
||
This was happening "rarely" on our SM 2.0 'unit test' build, recently we switched to packaged 'crashtest' and 'reftest' tests runs, and it is now happening quite often :-/ I don't know what (change) caused this increase exactly, but it's even more visible as it happens on both tree columns at once. So a solution/workaround is more needed than ever...
Attachment #429400 -
Flags: review?(dbaron) → review?(ted.mielczarek)
Comment 13•14 years ago
|
||
Comment on attachment 429400 [details] [diff] [review] (Av1) Add .NOTPARALLEL to ensure autoconf.js is fully generated before proceeding This is a sledgehammer approach. Just make the "make-xpi" target depend on autoconf.js, like: make-xpi: autoconf.js
Attachment #429400 -
Flags: review?(ted.mielczarek) → review-
Assignee | ||
Comment 14•14 years ago
|
||
Per your comment 13 ;-)
Assignee: nobody → sgautherie.bz
Attachment #429400 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #430649 -
Flags: review?(ted.mielczarek)
Updated•14 years ago
|
Attachment #430649 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 15•14 years ago
|
||
Comment on attachment 430649 [details] [diff] [review] (Av2) Make "make-xpi" target depend on autoconf.js [Checkin: Comment 15] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3151f58fac89
Attachment #430649 -
Attachment description: (Av2) Make "make-xpi" target depend on autoconf.js → (Av2) Make "make-xpi" target depend on autoconf.js
[Checkin: Comment 15]
Assignee | ||
Comment 16•14 years ago
|
||
So many oranges for such a simple fix :-/
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite-
Keywords: dogfood
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [See comments 0 & 4 & 8] [orange] → [fixed1.9.1.9] [orange]
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [fixed1.9.1.9] [orange] → [fixed1.9.1.9]
You need to log in
before you can comment on or make changes to this bug.
Description
•