183849 - hang due to obsolete selectedSkin references in <profile>/chrome/chrome.rdf

Status: RESOLVED DUPLICATE of bug 144027

(Core :: XUL, defect)

Description

[John Morrison]

I was looking into the reported hangs that are somehow related to XUL
fastload, when I managed to hit this (or possibly this) hang in my own
build. After poking around a bit I worked out what was wrong.

First, my symptoms when I hang (to be specific):

1) the browser starts initially OK, and can bring up the profile manager
2) it validates the already existing fastload file (right mtimes, paths 
   and checksum). 
3) it proceeds on to call nsXULPrototypeCache::GetPrototype for the various
   xul files, calling into nsXULPrototypeCache::StartFastLoad to successfully
   mux the document out of the fastload file.
4) However, after that, I'm not sure where it goes in the code, but it 
   wind up not showing the window, and the app is just sitting there spinning
   the main event loop forever. [Note: I don't see any large gain in memory
   size and the fastload file does not increase in size].

If I then delete the fastload file (XUL.mfl) and then try starting, the
application successfully starts up, recreating the fastload file in the
process.  However, if I then shut down and restart I wind up hung again. (This
differs, I think, from some other reports which indicated that once they
deleted the fastload file, they no longer had problems starting up. So this
may not be the same bug, at least not exactly).

I then worked out how I got myself into this state. When I was looking at bug
169777, in the strace log, I could see it was stat'ing
<profile>/chrome/littlemozilla_12.jar
along with the other jar files to check it's mtime. In other words,
littlemozilla was one of the dependencies listed in the fastload footer.

So, I installed the latest littlemozilla skin to check if it was there in my
XUL.mfl. (Unfortunately, I now forget whether it was put there or not; I guess
I'll have to try that again and update this bug). This littlemozilla can also
install itself into dist/bin/chrome as well as <profile>/chrome, and I took
the dist/bin route.

When I left last night, I trashed my dist and updated to the tip (and that was
my fatal mistake, as they say). This is what is causing me to hang:

I still have references to littlemozilla as the selectedSkin in
<profile>/chrome/chrome.rdf
but I no longer actually have that skin available. But I also don't have some
of the packages for which littlemozilla is the selectedSkin, namely "enigmail", 
"multiviews", "aim", "home", "forms", and "browser".

When I remove the littlemozilla references from my profile chrome.rdf, I 
can now start the browser again with hanging, even when using the allegedly
bad fastload file that was hanging before.

Comment 1

[John Morrison]

Attachment: <profile>/chrome/chrome.rdf that results in a hang.

Comment 2

[John Morrison]

I just checked another 'bad' XUL.mfl that someone emailed to me, and it has
"bannerblind.jar" in the fastload dependencies footer.

Comment 3

[John Morrison]

I can reproduce this exactly as an end user might. 

1) install mozilla1.2b release into c:\foobar
2) install the littlemozilla theme (version 1.2), then switch to using it.
     http://themes.mozdev.org/themes/littlemozilla.html
3) shut down, then restart in the littlemozilla skin.
4) switch back to using the classic skin.
5) shut down, then restart in the classic skin.
6) install mozilla1.2.1 release into c:\foobar
7) start browser, then quit.
8) start browser again. It hangs. (or if it didn't this time, then 
   shut down and try to restart again; it will hang).

But, it's even simpler. Take a perfectly clean working build. Then make the 
contents of <prof>\chrome\chrome.rdf like this. Note the 'modern-fu/1.0'. 
Browser hangs. (And I'm not picking on chatzilla; but it is the non-existent
skin for selectedSkin on chatzilla that leads to the hang).

<?xml version="1.0"?>
<RDF:RDF xmlns:c="http://www.mozilla.org/rdf/chrome#"
         xmlns:NC="http://home.netscape.com/NC-rdf#"
         xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <RDF:Description about="urn:mozilla:package:chatzilla">
    <c:selectedLocale resource="urn:mozilla:locale:en-US:chatzilla"/>
    <c:selectedSkin resource="urn:mozilla:skin:modern-fu/1.0:chatzilla"/>
  </RDF:Description>
</RDF:RDF>


It is true that I can fix the hang by blowing away the fastload file. 
But the hang will return on the second start after that.

I recalled bz explaining this on irc, when he was doing the fix for 
bug 183165:

<bz> fastload plays into it by messing with how sheets are loaded
<bz> in non-fastloaded XUL sheets are loaded via LoadStyleLink
<bz> asynchronously
<bz> in fastloaded XUL, they are loaded via LoadAgentSheet.
<bz> synchronously
<bz> the unicode decoder used is different in the latter case

Comment 4

[Asa Dotzler [:asa]]

probably release note worthy for alpha. not gonna hold the alpha release for this. 

Comment 5

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2.1) Gecko/20021130]

Comment 3 "simpler case" seems to "WfM":

With my working profile, I tried to remove my XUL.mfl, modify my chrome.rdf,
then restart Moz 3-4 times:
*I added the ChatZilla description to my existing file;
*I replaced 'classic' by 'modern-fu' for 'editor', and/or 'navigator';
*I created a new file with your 9 lines only. (Then Moz recreated the other lines)

It never failed, and my XUL.file was always recreated/maintained to 776 KB.

I then tried without deleting my XUL.file: it remained untouched (same
timestamp) at 2.444 KB.

NB:
 *ChatZilla was never installed.
 *Modern Theme was the default when I first installed a Moz build (that was
monthes or a year ago); Classic Theme is selected since then. I never used any
other theme/skins.

PS:
 *I did not try the "end-user case", nor your previously attached RDF file.
 *There may be some prerequisites for the "simpler case" !?
 *May be this bug "could" be made dependent of buf 134576 ?
 *If the hang is truely reproductible, I concur that it would not be a bug
169777 duplicate.

Comment 6

[John Morrison]

Frankly, I don't care that you can't reproduce it. I can. And I think the 
developers on this bug know that I'm usually right. If they can't reproduce
this hang given comment #3, then I'll gladly help them understand my 
instructions. But until one of them comments, I don't think this bug report
needs any more information. Thanks.

Comment 7

[John Morrison]

Hmm, that sounded a trifle harsh. Thanks for all the work you have done in 
triaging these problems, and in drawing attention to them. I appreciate it
very much.

Comment 8

[David Castro]

*** Bug 184299 has been marked as a duplicate of this bug. ***

Comment 9

[Andrew Hagen]

Dupe.

*** This bug has been marked as a duplicate of 144027 ***