184589 - after Mozilla crash, XBL error occurs, problem with XUL.mfl

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Davey]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2; MultiZilla v1.1.32 final) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2; MultiZilla v1.1.32 final) Gecko/20021130

Mozilla froze, and had to be killed using ctrl+alt+del then end process, it took
about 15 tries, and finally it died. Upon restarting Mozilla, the following
error displayed:

Error launching browser window:no XBL binding for browser (image attached)

this was sorted by someone (bz) in #mozilla telling me to remove the XUL.mfl

Reproducible: Didn't try

Steps to Reproduce:




XUL.mfl attached, along with image showing error

Comment 1

[Davey]

Attachment: XUL.mfl, compressed in using zip format

Comment 2

[Davey]

Attachment: Image showing the error message displayed by Mozilla

Comment 3

[Boris Zbarsky [:bzbarsky]]

Just to clarify:

1)  The error was repeatable on startups following the Ctrl-alt-del
2)  The XUL.mfl attached to this bug is the corrupted one.

Seems like our detection of corrupt fastload files fails here; it would be good
to figure out why...

Comment 4

[John Morrison]

Um, so all the *.jar dependencies, according to XUL.mfl, have an mtime of May
31, 2002, which is consistent with mozilla1.0. The computed checksum matches
the stored checksum. The version number is 0xfeedbeec which is the mozilla1.0
branch version; the current trunk value is (0xfeedbeef - 6). Also, the XUL.mfl
in the attached zip file had a timestamp of June 9, 2002.

The footer information looks reasonable (mNumIDs == 1, mNumSharpObjects == 17,
mNumMuxedDocuments == 118, mNumDependencies == 14), except for mNumIDs, only
because I'm not sure what values that takes.

If you started with that file in your profile as XUL.mfl with version 1.2.1,
first you would fail the mtime comparison on the first dependent jar file, and
would delete the XUL.mfl and abort the fastload. But if you for whatever
reason, got past that check, you would fail the version check and
delete-and-abort. (I stepped through this code to be certain). 

I also started with a build that doesn't do those checks, and even though it
asserts like crazy I still manage to start and the UI is fine. No alert.

I'm not saying that you didn't experience what you describe, but there is no
conceivable way, in my mind, that this can be the XUL.mfl that you had to 
delete. It can't be.

Comment 5

[Simon Crute]

Hi, 
  I've also got a problem that seems to be caused by a corupt XUL.mfl 
If this XUL.mfl file is in place then the following actions cause a lockup. 
either 1) anything which causes the stored passwords to be read, or 2) changing
the theame from modern to clasic. 

When mozilla hangs, is just sits in the task list eating more and more memory. 

I can attach the xul.mfl file if that will help.

If this is not related to this bug, just say and I'll rais a new one.

Comment 6

[John Morrison]

What you describe sounds more along the lines of bug 169777. But I would 
like to have a look at your XUL.mfl file, so if you can either attach it
to that bug (in zip or gzip format), or if it's too big, email it to me
<[e-mail]>. Thanks.

Comment 7

[Bill Chao]

I recently had a similar problem where the file XUL.mfl is corrupted somehow and
Mozilla Browser will not start.  All I see is the splash screen and if you look
at the task manager, it will start to grab memory.

A website had suggested a brute-force rename of each file in the profile
directory to see which file is the cause.  This was the last file I renamed.

I have a copy of the bad XUL.mfl file.

Bill

Comment 8

[John Morrison]

re: comment #7, This is all fixed in 1.3b, I believe.

re: this bug overall, again, this is fixed in current builds, so marking 
worksforme.