513943 - [SeaMonkey 2.1, leak test] cb-seamonkey-linux-01 fails with "WARNING: ... nsCSSLoader.cpp, line 2101" followed by "ASSERTION: Could not load scrollbars.css.: 'gStyleCache->mScrollbarsSheet'"

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

...

...
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1251760449.1251765900.5187.gz&fulltext=1
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.

Comment 1

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> ...
> 
> ...

I looked back to
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1251530187.1251535864.26633.gz&fulltext=1
Linux comm-central-trunk leak test build on 2009/08/29 00:16:27

Comment 2

[Robert Kaiser]

I'm clobbering that tree on that machine, let's see if it helps.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)

Assuming
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1251835020.1251841051.11911.gz
Linux comm-central-trunk leak test build on 2009/09/01 12:57:00
had been clobbered,
then that did not fix this bug.

Comment 4

[Serge Gautherie (:sgautherie)]

Really not fixed: 7 failures in a row (and counting).

Comment 5

[Serge Gautherie (:sgautherie)]

Neil told me (irc) that bug 514959 might fix this...

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> Neil told me (irc) that bug 514959 might fix this...

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1252367744.1252370224.19699.gz
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
}

Code is
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSLoader.cpp
{
2036 CSSLoaderImpl::InternalLoadNonDocumentSheet(nsIURI* aURL, 
...
2100   rv = LoadSheet(data, state);
2101   NS_ENSURE_SUCCESS(rv, rv);
}

Comment 7

[[e-mail]]

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

Comment 8

[Robert Kaiser]

OK, reading that comment, I will clobber that tree on that machine again.

Comment 9

[Robert Kaiser]

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

Comment 10

[Serge Gautherie (:sgautherie)]

Still not sure why this Linux box only was affected...

V.Fixed, anyway.

Comment 11

[[e-mail]]

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

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)

Do the other Linux "VMs" use a Windows file system??

Comment 13

[Robert Kaiser]

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

Comment 14

[Serge Gautherie (:sgautherie)]

Bug 489483 would help to catch/fix these issues automatically, then.