Linux comm-central-trunk leak test build on 2009/08/31 16:14:09
###!!! ASSERTION: Could not load scrollbars.css.: 'gStyleCache->mScrollbarsSheet', file /builds/slave/comm-central-trunk-linux-debug/build/mozilla/layout/style/nsLayoutStylesheetCache.cpp, line 89
This box (only) is perma orange on this job.
(In reply to comment #0)
I looked back to
Linux comm-central-trunk leak test build on 2009/08/29 00:16:27
I'm clobbering that tree on that machine, let's see if it helps.
(In reply to comment #2)
Linux comm-central-trunk leak test build on 2009/09/01 12:57:00
had been clobbered,
then that did not fix this bug.
Really not fixed: 7 failures in a row (and counting).
Neil told me (irc) that bug 514959 might fix this...
(In reply to comment #5)
> Neil told me (irc) that bug 514959 might fix this...
Linux comm-central-trunk leak test build on 2009/09/07 16:55:44
It did not :-|
Ah, the assertion is preceded by
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /builds/slave/comm-central-trunk-linux-debug/build/mozilla/layout/style/nsCSSLoader.cpp, line 2101
2036 CSSLoaderImpl::InternalLoadNonDocumentSheet(nsIURI* aURL,
2100 rv = LoadSheet(data, state);
2101 NS_ENSURE_SUCCESS(rv, rv);
(In reply to comment #6)
> (In reply to comment #5)
> > Neil told me (irc) that bug 514959 might fix this...
> It did not :-|
It fixed it for me locally after a clobber; it won't fix depend builds.
What's happening is that both suite's jar.mn and toolkit's jar.mn provide a location for scrollbars.css; suite says it's in classic.jar and 1.9.1 toolkit also says it's in classic.jar so that's OK; unfortuantely trunk toolkit now puts it in toolkit.jar which results in a conflict. The problem on Linux is that it reads manifest files in creation order, and toolkit.manifest is created before classic.manifest, so classic.manifest wins and points to the bogus location. This isn't a problem on Windows because the file system enumerates files alphabetically and so toolkit.manifest wins because it is read last.
OK, reading that comment, I will clobber that tree on that machine again.
The box has now done a successful trunk leak test build cycle, see http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1252426721.1252431799.17018.gz&fulltext=1
Still not sure why this Linux box only was affected...
(In reply to comment #10)
> Still not sure why this Linux box only was affected...
Because the Windows file system enumerates files in alphabetical order while the Linux file system enumerates them in creation order and the bogus line is sensitive to the order in which it is processed.
(In reply to comment #11)
Do the other Linux "VMs" use a Windows file system??
(In reply to comment #12)
> (In reply to comment #11)
> Do the other Linux "VMs" use a Windows file system??
No, but as all of them are doing dep builds, they might never have created them in the wrong order and therfore wouldn't have run into the problem.
Bug 489483 would help to catch/fix these issues automatically, then.