Closed Bug 169777 (FastLoadHang) Opened 22 years ago Closed 22 years ago

Corrupted XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs (not crashes) Mozilla/MailNews/etc (when opening Edit > Preferences, or at "random")

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sgautherie, Assigned: jrgmorrison)

References

(Blocks 1 open bug)

Details

(Keywords: hang, regression, Whiteboard: [adt1])

Attachments

(13 files, 2 obsolete files)

bzipped corrupt XUL.mfasl (1/2)
275.00 KB, application/octet-stream
Details
bzipped corrupt XUL.mfasl (2/2)
257.80 KB, application/octet-stream
Details
bzipped strace log from Moz 1.2.1 using corrupt fasl
64.01 KB, application/octet-stream
Details
stack trace for the "reading infinitely" hang
3.85 KB, text/plain
Details
memory and cpu usage while bug occurs
20.99 KB, image/png
Details
XUL.mfl "corrupted" on FormManager acces (part 1/2)
277.10 KB, application/octet-stream
Details
XUL.mfl "corrupted" on FormManager acces (part 2/2)
277.10 KB, application/octet-stream
Details
XUL.mfl "corrupted" on FormManager acces (c87, part 1/2)
283.33 KB, application/octet-stream
Details
XUL.mfl "corrupted" on FormManager acces (c87, part 2/2)
283.33 KB, application/octet-stream
Details
Simple Windows batch file to automatically backup XUL.mfl (c95)
349 bytes, application/octet-stream
Details
XUL.mfl corrupted on Messenger access (c97, part 1/2)
205.35 KB, application/octet-stream
Details
XUL.mfl corrupted on Messenger access (c97, part 2/2)
205.35 KB, application/octet-stream
Details
corrupted (?) XUL.mfasl file, Christian Koch
70.02 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910

Everything was fine since I installed v1.2.a.

Tonight, I activated the Password Manager...
(This is something which I had not done before (with any release)... but I can't
say what actually causes the problem.)

After having closed and restarted Mozilla 1 to 3 times, I found out that I
couldn't access the Pref. anymore.


Reproducible: Always

Steps to Reproduce:
1. Edit > Preferences...

Actual Results:  
Mozilla seems to briefly access the disk,
then it freezes with "Preferences..." still highlighted in the opened "Edit" menu.

I have to kill the program from Win95 (C-A-D + End_Task) !


Expected Results:  
Close the menu, then display the Pref. dialog, as usual.


After a few tries, I discovered that
*if I rename my (2.138 KB) XUL.mfl to something else; it works again !
*if I rename it back to normal, the problem reappears.


But:
*I think that the culprit file (452 KB when zipped) is too big to be attached to
this bug.
*I don't know if I have any mean to test/see what has gone wrong with this file.
*I don't know how to "reproduce" this file going right to bad :-(

The points are:
*Why/how could this file become bad ?
*Could Mozilla be improved to detect this state and invalidate the file ?
 *I am refering to *.mfasl files mentioned in the release note.
broken file:invalid -> please reopen if you find a way to reproduce this
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021016"

I still do not know why/how exactly, but it happened again.

What I remember that happened recently:
 (I don't remember in what order, or if during the same "session".)
*I activated Password Manager...
*Mozilla had been closed; but when I shut down W95, Mozilla crashed (the process
may have been hanging in the background without window): it turned out I had to
hard reset the computer...

I'll try to pay more attention in case it happen again (may be after
installation and setup of the next release :-().

Certainly not INVALID. This has just happened to me too.
Deleting XUL.mfl helped, but there must have been a bug
in Mozilla that caused that file to become corrupt in
the first place. Also, ending the Mozilla task because
of the freeze when trying to view the prefs dialog
resulted in my disk cache being resetted the next time
Mozilla was started.

not invalid.

If you think this bug is a dupe of something else, make this bug
dependent on the prime bug and keep this bug visible.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
*** Bug 169979 has been marked as a duplicate of this bug. ***
*** Bug 172826 has been marked as a duplicate of this bug. ***
*** Bug 173359 has been marked as a duplicate of this bug. ***
*** Bug 174247 has been marked as a duplicate of this bug. ***
*** Bug 179742 has been marked as a duplicate of this bug. ***
*** Bug 180197 has been marked as a duplicate of this bug. ***
*** Bug 174874 has been marked as a duplicate of this bug. ***
This bug is ready to be confirmed. I've added TalkBack reports to one of the dupes:
TB12656864G - Moz.1.2b freezes for 4 minutes and then crashes opening the sidebar
TB14005564G - Moz2002111408 freezes for 5 mins, memory usage goes up, and then
crash - accesing Tools->Message Filters in MailNews

chg OS per dupes
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Summary: My XUL.mfl freezes Mozilla when I try to view the Preferences → Corrupted XUL.mfl freezes Mozilla when opening Edit | Preferences
After checking all the dupes which "dwx" found:

*The only clue for an explanation of the cause of the corruption is in bug
179742: (Linux) system crash. (see my comment 2 (Win95))

*I noticed that in my case(s), the XUL.mfl was never renamed to XUL.mfasl (so
far). (see my initial description)

*Then, I wanted to try to reproduce the "hang", but wait for a "crash" (as
described in comment 12).
 *I put back my corrupted XUL.mfl file saved on 2002.10.19.
 *But the problem did not showed: instead my "corrupted" XUL.mfl file size
dropped from 2.831 KB to 889 KB :-< (It must have been recreated or something:
my "good/actual" XUL.mfl is 2.917 KB theses days.)

*If the hang happens again, I'll try and wait for the crash and TallBack to come up;
 I'll also pay more attention if my Win95 crashes with Mozilla opened.

*Maybe a system crash is not needed: killing a running Mozilla (?), or a Mozilla
crash (!), could be enough to corrupt the file ??
*The other question remains: could Mozilla detect (and correct) the corrupted file ?

Stephen, can you retreive Talkback data please: TB14005564G ?
Assignee: asa → hyatt
Component: Browser-General → XP Toolkit/Widgets: XUL
Keywords: stackwanted
QA Contact: asa → shrir
Whiteboard: TB14005564G
SIGIOT: Abort or IOT Instruction: (signal 6)

that's it, in entirety
Having the same problem; two different times.  First time I was trying to select
and print multiple emails (CTRL clicking the ones I wanted).  Mozilla hung and I
had to End Task it.  On subsequent attempts to compose a new mail, Mozilla hung
(lots of CPU usage and memory IO, but no results).  Renaming xul.mfl restored
full functionality.  Don't know if the initial hang was the problem or a symptom
of the file being bad in the first place.

Today, tried to Send Link from the File menu; Mozilla hung.  Renaming xul.mfl
restored full fuction again.

W2K (SP2), Moz 2002101612.
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126"

Bug still there.

It happened once again (a few hours after replacing v1.2b by v1.2 :->):
 *No operating system crash occured, before or after.
 *I waited for several (at least 7) minutes for Moz to crash and TalkBack to
start: it did not happen, even if Moz was not responding and marked so by Win95;
I eventually killed Moz.
 *The "faulty" XUL.mfl was about 3.5 MB.
 *I still don't know how to reproduce it (== "broke" the file) :-(

Happened to me too - upgraded to 1.2 yesterday - just locked today.
xul.mfl = 2.5 MB, deleting helped.
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126]

Upgraded yesterday from 1.2b (never occured) to 1.2 (locked today).
Bad XUL.mfl was 4,135,345 Bytes.

"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126"

(Making bug summary more general: per reports, and first hand experience !)

I happened again:
 *The first time that it happens (to me):
  *twice with the same release :-<
  *not with the "Opening Preferences" case:
   *I was trying to access a page for which I have PassWord manager enabled:
    the top of the page appears, then Moz freezes ... It could be at the time
that it should display the Login selection (I have "2 PassWords" for this page) !?
 *(file size was 2.340 KB)
 *I waited for +/- 10 mn, but nothing happened: I killed the task.
 *Nothing special happened recently: no crash (Win or Moz), no new options, etc.
  (Well, I did move some BookMarks yesterday...)

Still no hint on what could be the trigger.

But, since once the file has supposedly got "corrupted", the symptom becomes
100% reproductible:
*Is there any kind of environnement variable or others that could be set to
trace what Moz does untill/while it freezes ?
*Or is there any mean to "analyze" some "corrupted" files in a attempt to find
out some clues ?
Summary: Corrupted XUL.mfl freezes Mozilla when opening Edit | Preferences → Corrupted XUL.mfl freezes Mozilla (when opening Edit | Preferences, or at "random")
Possibly related problems or dups:
Bug 167523, Bug 178208, Bug 182795, Bug 158285 comment 16

In reply to comment 22:

*Bug 158285 comment 16
 *"Possibly related": may be...
 *"Duplicate": I would say no, since that bug is not a hang(/crash) issue.

*Bug 182795
 *It does look like to be a duplicate of this bug.

*Bug 178208
 *The question has been asked there, as a duplicate of bug 167523.

*Bug 167523
 *"Duplicate": could be, yes. (and there seems to be some more dupe candidates
by reading all the comments of all theses bugs (recursively).)
 *My question is: what is the difference between files named 'XUL.mfl',
'XUL.mfasl' and "XUL FastLoad File" ?
  Depending on the answer, I see from 1 to 3 "root" bugs to keep, and mark all
the others as dupes.
 *See also comment 4: using 'dependent' instead of 'duplicate' if needed.

See my comment 21;
This is the only thing which I know so far.

Good: starting with no XUL.mfl file.
Bad: starting with the "corrupted" XUL.mfl file.

If this is irrelevent, feel free to say so and "discard" this attachement.
jrgm, any insight?

/be
Assignee: hyatt → ben
QA Contact: shrir → jrgm
> what is the difference between files named 'XUL.mfl', 'XUL.mfasl' and "XUL 
> FastLoad File" ?

None, in terms of functionality or format. They are simply platform-specific 
names for the same file.

> jrgm, any insight?

Unfortunately not. If someone can attach one of these corrupted fastload files
to this bug (in gzip or zip format), I'll try to hack up a build that bypasses
the normal timestamp/path/checksum checks, and see if I can reproduce the hang 
and get a proper stack. Thanks in advance.

*** Bug 182795 has been marked as a duplicate of this bug. ***
Blocks: FastLoadMeta
Since there are MANY duplicates of this bug, I modify the summary again, in an
attempt to make it even more "catch-all"...


Also, I made this bug and bug 167523 block bug 134576.


Then I went through bug 167523 (and some/many others) links.

Here are some links (if not dealt with already) in reply to comment 26:

*Crash:
 *Already Dupe this bug: bug 174874, bug 172826 comment 4,
 *May be: bug 176827 comment 4

*"Corrupted" XUL Files:
 *See bug 167523 comment 1, bug 172388 comment 1

*Trace:
 *See bug 179346 comment 5 (and 6)

(I gave up on bug 106021: too many other links over there. (Fed up :-())
Summary: Corrupted XUL.mfl freezes Mozilla (when opening Edit | Preferences, or at "random") → "Corrupted" XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs Mozilla/MailNews/etc (when opening Edit | Preferences, or at "random")
I had recently send a corrupted mfl to John Morrison, and I wanted to check if
this file both hanged and memory hogged (which I had seen in one case) - and
when I copied over the corrupted mfl to my profile and started Mozilla, Mozilla
ran!?
The XUL.mfl file got decreased in filesize though - from around 2.5 MB to ~700 kB
ohh bugger - disregard comment #29. Just realized that I upgraded from 1.2 to
1.2.1 which invalidates the old fastload file - sorry for spam :/
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Just wanted to add that this happened on Linux 1.2.1 release version.
Don't know what triggered it but deleting XUL.mfasl fixed it.
This XUL fastload file seems to be corrupt. It was generated by Mozilla 1.2.1
on Linux 2.4.18, RPM install. (Part 1 of 2; cat together to restore)
Second part of the corrupt fasl (append to first part and bunzip2 to restore)
Log from 'strace' tool of Moz 1.2.1 using previously attached corrupt fasl.
bunzip2 to restore.
Don't know if you'll be able to reproduce from this, but I was. I got this
corrupt XUL.mfasl from:

Linux dhcppc3 2.4.18-18.7.x #1 Wed Nov 13 20:29:30 EST 2002 i686 unknown
Red Hat Linux release 7.2 (Enigma)
Including RPMs:
glibc-2.3.1-6
mozilla-nss-1.2.1-0_rh8
mozilla-mail-1.2.1-0_rh8
mozilla-1.2.1-0_rh8
mozilla-js-debugger-1.2.1-0_rh8
mozilla-chat-1.2.1-0_rh8
mozilla-psm-1.2.1-0_rh8
mozilla-nspr-1.2.1-0_rh8
mozilla-dom-inspector-1.2.1-0_rh8

Actually this is the second time I ran across this bug. The first time, I just
killed my XUL.mfasl (experimentally, along with many other unnecessary files)
and problem was solved. This time I kept the corrupt fasl. It is attached.

I reproduce by using a separate test profile. I copy the corrupt XUL.mfasl over
the working copy in the profile under my ~/.mozilla dir. I start Mozilla with
the test profile, and when it comes up, select Edit | Preferences. The app
freezes with 100% CPU. Attaching also the strace log in case you cannot
reproduce. The log clearly shows that Mozilla is endlessly trying to read from a
stream open on XUL.mfasl, and that it reads all the way to the end:

read(20, "\0\0002chrome://wallet/content/walle"..., 8192) = 3197

shows the last 3197-byte block. After that, it apparently does not understand
that it is at EOF, since it endlessly tries to keep reading:

read(20, "", 8192)                      = 0

Looks like some kind of bad EOF detection, possibly only on corrupt caches.

I only started seeing this under Mozilla 1.2.1, not in 1.1 or 1.0.

Why is severity "minor"?! If you do not know the workaround - delete
~/mozilla/*/*/XUL.mfasl - it is pretty major. Your Mozilla profile becomes
unusable. I had data loss when I tried to send a mail message that I had spent a
while composing and Mozilla chose that moment to freeze.
     ***** In reply to comment 35:


I did not though to split the zipped file :-<

*I think that this tip should be added to the message which tells that the
attachment is too big. (unless it is already, and I did not notice it)

*I still have my two files created by v1.2:
If John Morrison (comment 26) wants them, I would upload them.


At first, I set severity to minor, because I had the Preferences case only,
which is "harmless" (besides being quite annoying) if no work is in progress...

I suggest to leave it as is while we are all still trying to find a clue on what
the problem actually is: remember comment 1 when this bug was even briefly
considered invalid !
On the contrary, once the source of the problem is identified, I would raise
severity to major (or even critical).
Rest assured that my main goal was to get attention (even before discovering all
the duplicate reports, and bug 134576): I think this is done now, and I feel
that with some luck this problem could be solved rather sooner than later :-)

Thanks for attaching the XUL.mfasl and the strace output. Here's 
some additional random notes.

The startup proceeds normally at first, and has loaded most everything
including initializing the cache, session history, prefs, layout, 
content, bookmarks, wallet... It has done the initial 32 byte read
of the fastload file, read the header, and read the footer. The file
is apparently 3591293 bytes in size (which agrees with the size of the
attached XUL.mfasl). 

It stats the jar files, including '<salt>/chrome/littlemozilla_12.jar'
in the user's profile directory. It has apparently passed the
path/mtime/checksum sanity checks, and then it reads the entire
fastload file. It then does some further seeking and reading within
the file.

It then proceeds on the read localstore.rdf, stats and reads some of 
the overlays.rdf. It proceeds on, I think creating the window, and 
then reads in panels.rdf (among other things).

Okay, so that's all fairly normal.

So, now we come to where things go wrong (although I don't know what
went wrong). The app reads the first 8192 bytes of XUL.mfasl again. 
Then there are a bunch of mmap2 requests for 2 to 4 GB of memory, 
then a mmap2 of 3583101 bytes which succeeds. 

The rest proceeds as Jesse describes, with it apparently reading
on forever. Suggest anything to you ben or brendan?
Severity: minor → major
Keywords: nsbeta1
Nav triage team: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: TB14005564G → [adt1] TB14005564G
I have the following behavior with 1.2.1 (NT4SP6 with the profile stored on a
network share [which is a Samba share from a Linux system]):

1. Mozilla hangs on startup (after displaying splash screen) if I don't delete
   the XUL.mfl file.
2. After I kill the hanged mozilla and delete XUL.mfl file, mozilla starts
   properly and creates a 800 KB XUL.mfl file.
3. After I exit mozilla (and it seems to exit properly, leaving no processes -
   I've disabled QuickLaunch), XUL.mfl remains in the profile, possibly larger,
   like 900 KB.
4. Back to (1).

Thus, on my system, creating a "bad" XUL.mfl seems to be repeatable (at least
for the moment - yesterday the behavior was different, but I had QuickLaunch
enabled).
re: comment 39. That's bug 183849. 
Jesse Glick: can you try to reproduce this again, and then use 'pstack(1)'
(/usr/proc/bin/pstack) to dump out the stack several times while it is 
churning away? Thanks. 

[I've tried to do this on Linux, but the version on Linux is having trouble 
dealing with the threads, unfortunately. I still haven't reproduced this on 
Linux, although I did get into this 'churn' in 1.2.1 release build on win32. 
But that build didn't have any symbols, so I couldn't tell much about what was 
happening. And since then I can't get to happen again].
Okay, so with the XUL.mfl that was helpfully provided to me by Brian Matzon
(via email), and after hacking the normal checks that prevent you from 
using a fastload file when the paths/mtimes/checksum do not match, I have
managed to reproduce this hang in a opt. build with symbols on win2k. I'm 
attaching the stack trace (before I lose it).

I'm going to poke around in my build and see why it is looping, and then 
try to reproduce this again to see what else I can learn.

I do have a question for Brian Matzon (and Jesse Glick). In both these 
fastload files, there is a dependency noted on a third-party app or skin.
My question is: what is the skin that you were using with the profile
with which you encountered this bug. Was it Modern, Classic, or the 
third-party skin.
The "infinite" loop is here,
http://lxr.mozilla.org/seamonkey/source/content/xul/document/src/nsXULPrototype
Document.cpp#373

373                   rv |= aStream->Read32(&referenceCount);
374 alecf    1.45     nsAutoString namespaceURI, qualifiedName;
375 sicking  1.40     for (i = 0; i < referenceCount; ++i) {
376 alecf    1.45         rv |= aStream->ReadString(namespaceURI);
377                       rv |= aStream->ReadString(qualifiedName);
378 sicking  1.40 
379                       nsCOMPtr<nsINodeInfo> nodeInfo;
380                       rv |= mNodeInfoManager->GetNodeInfo(qualifiedName, 
                                     namespaceURI, *getter_AddRefs(nodeInfo));
381                       rv |= nodeInfos->AppendElement(nodeInfo);
382                   }

where i is now at about 7,466,524 (after about 30 to 60 seconds of churning),
and referenceCount is 1,292,520,815 (which is a long way away :-). I'm 
past the point of the Read32 of the referenceCount, so I don't know why
it returned such a large number. (I'll have to restart and break earlier).
Whiteboard: [adt1] TB14005564G → [adt1]
if the xul-file is broken then that huge number may well be what is in there. It
is simple to fix that loop to bail on an error, however there are probably a few
more loops that has the same problem.

While we probably should fix them all I think it's much more important to try to
figure out why the fastload file gets corrupted. Loading using a corrupted
fastload file will always be bad performance wise since first we will probably
spend some time before we realize that the fastload file is broken. And on top
of that we will have to parse the real XUL files.
The XUL.mfl file has not been modified on disk since the app started. An
external utility is telling me that the current file position, is at the
end of file.

We do need to figure out what is "corrupted" and how. I'll not though that we 
did pass a checksum test before using the file, so it's not a 
physical corruption.

In reference to comment #c42:
Using Modern skin.
There is one assertion before it hits the semi-infinite loop.

###!!! ASSERTION: aFastId out of range: 'index < mNumIDs', file 
h:/mozilla4/mozilla/xpcom/io/nsFastLoadFile.h, line 319

where:
  aFastId == 3328654070
  index   == 3328654069
  mNumIds == 3

        const nsID& GetID(NSFastLoadID aFastId) const {
            PRUint32 index = aFastId - 1;
            NS_ASSERTION(index < mNumIDs, "aFastId out of range");
            if (index >= mNumIDs)
                return gDummyID;
            return mIDMap[index];
        }


NTDLL! 77f9f9df()
nsDebug::Assertion(const char * 0x1011e7cc `string', const char * 0x1011e7e4 
`string', const char * 0x1011e7f4 `string', int 319) line 280 + 13 bytes
nsFastLoadFileReader::nsFastLoadFooter::GetID(unsigned int 3328654070) line 319 
+ 35 bytes
nsFastLoadFileReader::DeserializeObject(nsISupports * * 0x0012ed1c) line 968 + 
15 bytes
nsFastLoadFileReader::ReadObject(nsFastLoadFileReader * const 0x02f08fc0, int 
1, nsISupports * * 0x016332c0) line 1044 + 32 bytes
NS_ReadOptionalObject(nsIObjectInputStream * 0x02f08fc0, int 1, nsISupports * * 
0x016332c0) line 149 + 20 bytes
nsXULPrototypeDocument::Read(nsXULPrototypeDocument * const 0x016332a0, 
nsIObjectInputStream * 0x02f08fc0) line 342 + 41 bytes
nsXULPrototypeCache::GetPrototype(nsXULPrototypeCache * const 0x014aa108, 
nsIURI * 0x01619298, nsIXULPrototypeDocument * * 0x0012f1a4) line 272 + 32 
bytes
nsChromeProtocolHandler::NewChannel(nsChromeProtocolHandler * const 0x014e78c8, 
nsIURI * 0x01619298, nsIChannel * * 0x0012f2a0) line 608 + 63 bytes
nsIOService::NewChannelFromURI(nsIOService * const 0x0101c998, nsIURI * 
0x01619298, nsIChannel * * 0x0012f2a0) line 514 + 40 bytes
NS_NewChannel(nsIChannel * * 0x0012f3bc, nsIURI * 0x01619298, nsIIOService * 
0x0101c998, nsILoadGroup * 0x02edd670, nsIInterfaceRequestor * 0x02f9ebe0, 
unsigned int 524288) line 164 + 20 bytes
nsDocShell::DoURILoad(nsIURI * 0x01619298, nsIURI * 0x00000000, nsISupports * 
0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int 1, 
nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 5182 + 91 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x02f9ebb8, nsIURI * 0x01619298, 
nsIURI * 0x00000000, nsISupports * 0x00000000, int 1, const unsigned short * 
0x02f8f5e0, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned 
int 1, nsISHEntry * 0x00000000, int 1, nsIDocShell * * 0x00000000, nsIRequest * 
* 0x00000000) line 5096 + 51 bytes
nsDocShell::LoadURI(nsDocShell * const 0x02f9ebb8, nsIURI * 0x01619298, 
nsIDocShellLoadInfo * 0x02f8f568, unsigned int 0, int 1) line 725 + 73 bytes
nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x014c7604, nsIDOMWindow 
* 0x00000000, const char * 0x0169f238, const char * 0x0041a71c, const char * 
0x0012fbb4, int 1, unsigned int 1, long * 0x015cc9e0, nsIDOMWindow * * 
0x0012fb98) line 781
nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x014c7600, nsIDOMWindow * 
0x00000000, const char * 0x0169f238, const char * 0x0041a71c, const char * 
0x0012fbb4, nsISupports * 0x02f73948, nsIDOMWindow * * 0x0012fb98) line 459 + 
48 bytes
OpenWindow(const nsAFlatCString & {...}, const nsAFlatString & {...}, int -1, 
int -1) line 512 + 97 bytes
OpenWindow(const nsAFlatCString & {...}, const nsAFlatString & {...}) line 443 
+ 17 bytes
LaunchApplication(const char * 0x02f7aad8, int -1, int -1, int * 0x0012fd2c) 
line 596 + 13 bytes
startupPrefEnumerationFunction(const char * 0x02f7aac8, void * 0x0012fd20) line 
749 + 30 bytes
nsPref::EnumerateChildren(nsPref * const 0x00ffab70, const char * 0x0041a4b0, 
void (const char *, void *)* 0x00403d80 startupPrefEnumerationFunction(const 
char *, void *), void * 0x0012fd20) line 653 + 11 bytes
HandleArbitraryStartup(nsICmdLineService * 0x01004c20, nsIPref * 0x00ffab70, 
int 1, int * 0x0012ff2c) line 803
DoCommandLines(nsICmdLineService * 0x01004c20, int 1, int * 0x0012ff2c) line 
855 + 26 bytes
main1(int 1, char * * 0x00277938, nsISupports * 0x002779b0) line 1490 + 22 
bytes
main(int 1, char * * 0x00277938) line 1902 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
Severity: major → critical
Keywords: stackwanted
*** Bug 182815 has been marked as a duplicate of this bug. ***
I've filed two code level bugs that note a couple of things that look wrong.

I've tried to use the XUL.mfasl attached by jglick on this bug, under both
linux and win32 debug, but can't reproduce the hang. However, I have managed
to reproduce the hang (well semi-infinite loop) on linux using the other 
XUL.mfl from win32 that I got from Brian Matzon.
> I've filed two code level bugs that note a couple of things that look wrong.

... and they are bug 184161 and bug 184339.
John: do you think we should try to make the load-code more robust for loading a
broken fastload file? I'm starting to have second thoughts, after all, if other
binary files get corrupted we don't handle that gracefully. Though maybe it
would be a good idea to fix the easy ones?
Jonas, I wrote the xpcom fastload code to be robust in the face of errors, but
something at a higher layer (in the callgraph; namely, xul) is not
sanity-checking deserialized integers, as you note.  It could, and perhaps
should, but then we'd have a harder time identifying and fixing whatever bug is
biting here.

I think it's best to feel the pain and get the fixes in.  I don't expect ongoing
bugs.  When I first did FastLoad for XUL JS scripts, jrgm buddied me and we got
it all nailed.  Now that Ben has added XUL elements to FastLoad, we're rounding
the same block.  We just need to press on for the finish line, again.

/be
     ***** In reply to comment 20

May be bug 184339 should block this one ? (and bug 134576 !?)

Same for bug 184161, if it is verified as a problem ?

Of course, my comment 53 refers to comment 50, not 20 :->


     ***** In reply to comment 52

As a "tester", I guess that the more I could ask is:
*Mozilla (which I use): let it hang so it is easier to identify and fix by the
"developpers".
*Netscape (which I do not use): make "XUL" detect and invalidate the corrupted
file so the "users" can work.

Of course, the more I think of myself as a "user" of Mozilla, the more I would
like it not to hang ... and let you look into the broken files :->

I tried using pstack from RPM, but it just dumped core on me when attempting to
attach to the Mozilla process; no idea why. (Worked as expected on other
processes, note.) May be some weirdness in how my copy of Mozilla is linked; I
am using a stock RPM build from mozilla.org. Hand-built pstack from sources said
for most of the Moz threads:

Could not attach to target.
continue: No such process

and for one of them, just hung without doing anything.

My broken XUL.mfasl was created under Little Mozilla 1.2 skin AFAIK. But the
freeze occurs with either that skin or with Classic. So while the corruption of
the file might be skin-specific, the freeze when reading it does not seem to be.

Is there anything else I can do to help?
Jesse: thanks for the information. Yeah, that's basically the same behaviour
I saw with pstack on my box. As for what else you can do, I don't have any
suggestions at the moment, but I'll let you know.

Serge: I added those other two bugs to the fastload tracking bug.
I have noticed than on my windows machine that wehenver I get the corrupted
XUL.mfl file Mozilla does not exit correctly.  What I mean is, I get similar
behaviour to Antonios Christofides in comment #39:

1) Mozilla won't start
2) I delete XUL.mfl
3) It starts up
4) I shut down and I can't start again because of a corrupt XUL file.

However, if I try to open another window while Mozilla is running, I cannot. 
Also if I close Mozilla, even with the quick launch disabled, Mozilla still
stays running in the background.  I can only get rid of it with ctr-alt-del. 
Only once I have manually killed mozilla and deleted the file can I open it
again (and then I can only open one window).

The point of this posting is to suggest the possible link between mozilla
staying in memory with quicklaunch disabled and the corrupted XUL file.  It
seems that the file gets corrupted immediately upon startup of mozilla, because
you can't open a new window even if you can get mozilla to run.  Just a clue as
to the source of the corruption.
*** Bug 179304 has been marked as a duplicate of this bug. ***
Just a quick note saying I've also had a problem with a freez from a corups
xul.mfl file. 
Mozila 1.2.1 on Win2k Sp2. 
Last thing I did (that I rememebr) was change the skil from clasic to modern. 

Mozilla loads, but hangs under either of these two conditions. 
1) anything with hits saved passwords (email, tools->manage passwords etc)
2) saving the preferances after trying to change the theam back to clasic. 

During the hang the mozila process was trying to use all available CPU and was
consuming memory quite fast. 

I can email anyome the xul.mfl file. Email me if you wish me to do so.
Blocks: profile-corrupt
*** Bug 183043 has been marked as a duplicate of this bug. ***
*** Bug 184725 has been marked as a duplicate of this bug. ***
*** Bug 178208 has been marked as a duplicate of this bug. ***
*** Bug 175794 has been marked as a duplicate of this bug. ***
*** Bug 184538 has been marked as a duplicate of this bug. ***
*** Bug 167523 has been marked as a duplicate of this bug. ***
Keywords: hang
Changing themes seemed to trigger this bug for me - workaround was to rename my
XUL.mfasl to something else, and then restart.

When mozilla was hanging, it tried to use all available CPU. Version 1.2.1
*** Bug 185856 has been marked as a duplicate of this bug. ***
Alias: FastLoadHang
i talked with jrgm on irc and realized that we have probably had this corruption
for quite some time, but my change to the format made us "hang" on the
corruption rather then just waste some time and then recreate the file.

If you guys want i could easily add a sanity-check so that we go back to the old
behaviour, but i think we all agree that it's better to find out why the file
gets corrupted instead.

It might be something to think about if we approach a milestone and still havn't
found the source of corruption though.
Let's nail this before 1.3 is done.

/be
Keywords: mozilla1.3
"If you guys want i could easily add a sanity-check so that we go back to the old
behaviour, but i think we all agree that it's better to find out why the file
gets corrupted instead." - are these mutually exclusive? If you can detect a
corrupted file, why not move it to $profiledir/XUL.mfasl.BROKEN, display an
error dialog requesting that the user report the bug (mention this bug #)
especially with steps to reproduce the broken FASL creation, then recreate a
working FASL.
the problem with adding the sanity-checks is that it will be a lot harder to
find the bug. We didn't even know of this bug until we started hanging on
corrupt fastload-file
*** Bug 185234 has been marked as a duplicate of this bug. ***
*** Bug 186329 has been marked as a duplicate of this bug. ***
Nominating for 1.3b.
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b+
I had this problem, using Mozilla 1.2.1 Build20021130 on Win2KSP2 with profile
on a network drive, too. The first time ever since I use Mozilla (from something
0.9.x on). I didn't touched skins (using modern) or preferences. The only
remarkable thing was, that mozilla hanged up while browsing a page I use very
often and I couldn't start again - hang while showing splash screen and
consuming memory on full cpu load like shown in the attachement (<== !!).
Renaming the xul.mfl helped, renaming it to original reproduced this error.

Some more detailed description:
* Starting the browser first ("mozilla.exe"), mozilla hanged with exactly the
same behaviour like described above, while showing the splash screen - end.
* Starting mail first, using "mozilla.exe -mail" command line switch, mail
started up, but calling preferences hangs mozilla with same behaviour as
described above - end.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212]

First hang with v1.3a:

*Launched Moz, Cut&Paste a URL to download a file, I think it hanged (for some
seconds at least...) when it should have displayed the ("security") dialog to
choose what to do with the file.
*My XUL.mfl file was about 2.6 MB and dated yesterday night (not modified since).
 *But, for the first time (for me), after killing and restarting Moz, the
XUL.mfl file was recreated (from 900 KB and growing).
  *NB: Either the "corruption detection" code has improved somewhat in v1.3a, or
this case may be one that I never encountered so far, which is different from
this bug because Moz "auto-restored" itself.

*No clue on why it hanged (I had checked the Preferences case from time to time
since I installed v1.3a with no problem);
*And no XUL.mfl file left to send it by pieces :-<
 *Next time, I'll copy it before restarting Moz !

likely a dup of that hang bug jrgm filed...
*** Bug 185715 has been marked as a duplicate of this bug. ***
*** Bug 186903 has been marked as a duplicate of this bug. ***
*** Bug 186925 has been marked as a duplicate of this bug. ***
I just got bitten by this bug today, when upgrading from 1.2.1 to 1.3a.

I also just enabled Password Manager for the first time, using it to save my
mail server password.

Mozilla loads fine, but locks up completely when choosing Edit/Preferences.  As
described by others, it locks up with Preferences still highlighted on the
screen, as soon as the mouse button is released.

It did not crash for me, just freeze.  It did not thrash the disk or otherwise
seem to consume memory in an infinite loop.  Everything else in the browser
works fine, including restarting, except for opening Preferences.  I do have
Quick Launch enabled, if that makes a difference.

Deleting XUL.mfl from my profile directory made all the difference, and now
Mozilla works again! :)

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212]

2nd time with v1.3a:

*I was on a HttpS site, "First" time using 'Tools > Form Manager > Edit Form
Info' (with no form data saved before/ever).
*Like the first time: I waited a few seconds for the Form Manager to appear,
then I killed Mozilla, XUL.mfl content was recreated on next startup;
 *But this time, I had copied it before restarting :->

The "corrupted" file will be in folowing attachements...
From its timestamp, it must have been written during the hang, or soon before.

PS: Of course, no problem with the recreated file :-<

See comment 83.

Use "copy /b" to join this 2 part (splitted) zip file.
See comment 83.

Use "copy /b" to join this 2 part (splitted) zip file.
*** Bug 187246 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212]

"3rd" time with v1.3a: (2 days after comment 83)

*Start Mozilla -> 'Tools > Form Manager > Edit Form Info' -> hang !
*The problem stays until I delete manually my 'XUL.mfl'.

*Recent "unusual" activity:
 *Created a 'user.js' to add "AutoCompleteOverride" setting: worked fine.
 *Deleted my "xxx.w" (Form Info) file: found the hang on the next startup :-(

See comment 87.

Use "copy /b" to join this 2 part (splitted) zip file.
See comment 87.

Use "copy /b" to join this 2 part (splitted) zip file.
*** Bug 187713 has been marked as a duplicate of this bug. ***
No additional corrupted fastload files need be attached to this bug at this
time. Please refrain from attaching any additional fastload files unless they're
asked for. Thank you.
Whiteboard: [adt1] → [adt1] No more corrupted fastload file attachments needed at this time.
*** Bug 187713 has been marked as a duplicate of this bug. ***
Actually, I'll take more fastload files if/when people have them. (You can also 
just email then to jrgm@netscape.com). I'm working on a tool to dump out the 
structure of the fastload file so we can see where they are going wrong.

For the two XUL.mfl files attached by Serge, they are broken in different ways.
For the first one, the file is pretty much nothing by >100000 entries in the 
mIDMap table. For the second one, there is an entry in the mObjectMap table
that has a value of zero for the mCIDOffset (and a zero value of mStrongRefCnt
for that entry too).
Whiteboard: [adt1] No more corrupted fastload file attachments needed at this time. → [adt1]
Ah. Actually for the first Form Manager bad XUL.mfl, the problem really starts
because the footerOffset in the header is '0', and so it tries to interpret
the header's magic string as the integers for mNumIds, mNumSharpObjects, etc.
and gets counts in the billions. Whoops.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212]

I had another kind of behaviour:

Not a hang like the ones I am used to:
usually, I basically _see_ no activity, and it can last for quite some time.

This time:
1. Started Mozilla; splash screen appeared;
2. Xul.mfl file was recreated (I think so !?); but for "15"(+/-) seconds, I had
lots of disk activity (virtual memory consumption probably) ... and my available
disk space was reduced by about 60 MB :-(
3. Mozilla appeared.
4. I closed it, waited for Win95 to reclaim the disk space, restarted Mozilla.
5. It appeared with no unusual delay, and disk space was down by 10 MB only :-)

Of course, I don't have the initial XUL file: I'll try and see if I can create a
batch file to backup this file on every Mozilla startup...

PS: I don't think that this description exactly fits this bug, but I don't know
which one else to report it to.

     *****

See also for possible duplicates of bug 169777:
*bug 168516 comment 31
*bug 174473 comment 37
*bug 181068 comment 5
*bug 187114 comment 9
*bug 187291 comment 6
*bug 187675 comment 7
*bug 187687 comment 4
Summary: "Corrupted" XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs Mozilla/MailNews/etc (when opening Edit | Preferences, or at "random") → Corrupted XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs Mozilla/MailNews/etc (when opening Edit > Preferences, or at "random")
Attachment #107971 - Attachment description: Traces of "nsHttp:5": 1 good, 1 bad → Traces of "nsHttp:5": 1 good, 1 bad (20030105_SG: Disregard = the problem is in the XUL file.)
Attachment #107971 - Attachment is obsolete: true
(see comment 95)

Can be used to launch Mozilla.

Customize it to your paths and commands depending on your system.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212]

My new batch file has already been of use :->

New case (for me, but must already be in some dupes):
1. Start Mozilla;
2. Ctrl-2 to open Messenger;
3. hang, with auto XUL recreation on next startup !

I will attach the corrupted file to the bug,
and email the previous good file to jrgm.


NB:
*In bug 157760 comment 2, a question is asked about crashes (not hang) with low
available memory:
 *In my case, I do have little physical memory (64 MB) installed, but I do not
seem to have any virtual (disk) memory shortage at this time...
  Nevertheless, I make no conclusion on this fact.


PS:
*Is it best to carry on with this bug 169777 only, or could it be better to file
2 other generic bugs in order to separate the 3 cases 1) manual deletion needed
(like initial description) 2) file recreation on next startup (like this
comment) 3) auto-recover without hang (like comment 95) ?
*This also applies to corrupted file attachments: are you interested in files
for all cases, or some of them only ?

See comment 97.

Use "copy /b" to join this 2 part (splitted) zip file.
See comment 97.

Use "copy /b" to join this 2 part (splitted) zip file.
I reviewed 9 XUL fastload files with a tool to dump out the header and footer
information in the fastload files. (Thanks to Andy Lyttle, Eduard Rysavy,
Brian Matzon, Jesse Glick, Serge Gauthier, Dan Kegel, and Mike Coppins for
supplying them).

Of the nine files:

1) Six of nine had a zero mCIDOffset in mObjectMap entry: (one of which also
had a suspiciously high mStrongRefCnt of 64516 in another entry in the
mObjectMap).

2) One had a mCIDOffset of about 1.9 billion (and a mWeakRefCnt of 22840 for
the same entry).

3) One had a footerOffset of zero (which means it can't even find the
mObjectMap, mDocumentMap, etc.)

4) one had almost no information contained in the XUL.mfl file (and I have a
feeling it may not have been the actual file that caused the hang).

5) Four of nine had also installed third-party skins (or apps)

Okay, so off to go figure out how those entries in (1) are getting stomped on.

(Note: Serge also sent me a fastload file that he head backed up just minutes
before he hit this hang again. You can see that a previously valid entry in
the mObjectMap got zeroed out in the course of serializing prefs stuff,
download manager stuff and bookmarks stuff. Curiously, the entry that got 
clobbered was an entry that had a mStrongRefCnt of 962, although that may 
be just coincidence).
Over to Jan.
Assignee: ben → varga
*** Bug 187786 has been marked as a duplicate of this bug. ***
I received two more XUL.mfl files (by email). Neither used third-party 
skins/apps. In one case, there was a zero mCIDOffset in the mObjectMap table
(like most of the other hangs above). In the other case, there wasn't a 
zero entry, but there were bogus offsets (e.g., 44 million) in the mObjectMap.
[Also, for the second case, there was an entry in the mObjectMap that had 
an unusual mWeakRef count of 101, with an offset that didn't look right 
either].
*** Bug 188069 has been marked as a duplicate of this bug. ***
*** Bug 187944 has been marked as a duplicate of this bug. ***
*** Bug 187847 has been marked as a duplicate of this bug. ***
I have also found that the bookmark manage and file functions are affected by this.
env. Win 2000 pro  Moz 1.2.1
But the disk is not accessed "briefly" as in the original report.
The task manager reveals an amazing number of IO reads.
The disk is continually accessed, moxzilla hogs the cpu, and the machine is
basically locked till the mozilla process tree is killed.
Renaming the XUL.mfl file makes the problem disappear, at least temporarily.
*** Bug 188385 has been marked as a duplicate of this bug. ***
*** Bug 188572 has been marked as a duplicate of this bug. ***
*** Bug 188664 has been marked as a duplicate of this bug. ***
*** Bug 188576 has been marked as a duplicate of this bug. ***
*** Bug 188591 has been marked as a duplicate of this bug. ***
*** Bug 188700 has been marked as a duplicate of this bug. ***
I had the Edit->Preferences lockup too.  Didn't know what caused it, so I
re-installed 1.2.1.  All well, until the Control-F or Edit->Find lockup showed up.

I sent my XUL.mfl to jrgm (almost 3 Mb), then quit Mozilla in order to delete
XUL.mfl, but then I found that XUL.mfl had automagically decreased in size to
only 21 kb.  When I restarted Mozilla, XUL.mfl grew to about 2 Mb, but all was
well when I tried Edit->Find again.  I sent the new (correct) XUL.mfl of 2 Mb to
jrgm as well.
I reviewed several more fastload files submitted to me. (Thanks to Jim 
Belfiore, Peter Karbaliotis, Ralph Golden, Mike Cordeiro, William Davis, 
Joergen Ramskov, Kelvin, Martin Pisz, Thomas Graf, Gert Brinkmann, User Jaydub, 
Florian Racky, Bill McIver, and Erick Silkens for the additional files.)
They basically mirror the same sort of patterns described in comment 100.

If anyone can describe to me a step-by-step procedure, beginning with a profile
that has no XUL.mfl (or mfasl) and eventually leading to this hang, that would
be much appreciated. I've found one so far, although it's slightly unlike 
the case for these fastload files, as that case happens when starting from a
known-to-be-good fastload file.


*** Bug 188881 has been marked as a duplicate of this bug. ***
Mozilla 1.3a

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

SuSE7.3 with Linux 2.4.20 (Original from kernel.org-mirror) 

I had this problem twice in 3 days and never before.

I figured this problem out the second time. The first time I just deleted my
~/.mozilla/ after saving my mails and bookmarks.


I couldn't start the email-Window.
1. I pressed strg+2: Mozilla hangs with 100% CPU usage
2. I tried the E-mail-button in the Browserwindow: Mozilla hangs showing the
pressed button.

And I had this problem when visiting sites with 2 usernames stored in my
password manager. The window appears but crashes before showing my 2 usernames.


My corrupted file is 2,9MB (490kb as bzip2).

Initially my new file is 1,5mb now.
*** Bug 189027 has been marked as a duplicate of this bug. ***
*** Bug 181068 has been marked as a duplicate of this bug. ***
Is bug 157760 a dupe of this?
I've had this problem so often and for so long that I ended up starting Mozilla
with a bat file which deletes XUL.mfl and XUL.mfasl every time I run Mozilla. My
overall Mozilla experience improved greatly after doing this - crashes dropped
by at least 70%.
Given that many persons have trouble because of this bug, and that it seems very
difficult to discover the root cause, I propose the following:

In the next major (stable) release, remove XUL.* from Mozilla alltogether,
unless a solution is found for the bug.

I did some measurements for the start time of Mozilla.  Windows NT 4.0, nothing
else running except for Windows Explorer and some services et al, 128 Mb
physical, 350 MHz, Mozilla starts browser and mailer, no QuickLaunch or whatever
it's called.

First test:  start time *with*    XUL.mfl.  Average: 7 s.
Second test: start time *without* XUL.mfl.  Average: 9 s.

Both tests were done five times, preceded by three "dummy" (unmeasured) tests to
get the system, memory management, ... in a stable state.

I think the difference is so small that XUL.mfl is not needed.  I can do without
it, given that the system is much more stable if I consistently remove the file.
In reply to comment 121 and comment 122:

See comment 115 (and comment 96) on how you could help by providing corrupted
files created from scratch: if "lucky" you would be able to identify a
reproductible test case.

See comment 68 for what could be done for next major release.

Thanks.

In reply to comment 120:

This bug is about (all) hangs only: the browser "freezes" but is still +/- alive;
bug 157760 is about (a specific) crash: the browser gets killed by itself or the
operating system;

Thus, they are not dupes of each other;
The "relation" between them is acheived through bug 134576.

Thanks for asking :-)

For me, after creating a new profile, Mozilla always malfunction on
the next restart. Whether I restart with Profile Manager or with the
previous profile with -p command option, moving mouse cursor into a
Mozilla window always cause a system error. Keyboard navigation,
however, works. If I remove xul.mfl, I'm able to start w/ the
previous profile with -p command option fine. I have not found a
way to start my profile manager properly.

The problem happens after installing a zh-tw locale of Mozilla 1.0.1
(into a separate folder). deinstalling Mozilla (1.0.1 and 1.3a) and
reinstalling 1.3 does not help.
This bug (actually, bug 188744) will be fixed soon.  It was introduced after
mozilla1.0, when XUL elements were added to the FastLoad file.  Ben and I didn't
see the problem, but thanks to jrgm's tireless efforts, and to lots of help from
people who sent him their FastLoad files, it's clear what is going wrong.

We're not going to turn off FastLoad (we're fixing the bug), but if you want to,
use the nglayout.debug.disable_xul_fastload pref -- no need for a batch file.

/be
This bug seems to have two components: 1) the FastLoad file is becoming
corrupted for some reason and, 2) the browser's fault-intolerant response to a
corrupted FastLoad file upon startup. From the preceding discussion, it seems
clear that you've identified some changes to correct the second problem, but I
wonder if you now also understand why the FastLoad file(s) gets corrupted in the
first place. Or should we continue to look for reproducible cases where the
XUL.mfl file is damaged, as jrgm requested in comment #115? 
I'm not sure who "you" means in comment #127, but I said we're fixing the bug
that leads to corruption (1) -- we're not wallpapering over it with some
defensive code (2) that attempts to invalidate corrupted FastLoad files.

We have enough defense against corruption caused by other programs messing with
the file.  We just need to fix the bad bug introduced after 1.0 to FastLoad,
with the XUL prototype element serialization/deserialization changes.

/be
*** Bug 189210 has been marked as a duplicate of this bug. ***
This bug doesn't occur with Phoenix. That might not mean anything, but OTOH it
could mean that this bug is related to a product that Mozilla has but Phoenix
does not. One such product that has also frequently been mentioned in duplicates
is Mail/News. Maybe this bug is related to Mail/News.

This bug is a regression. It doesn't occur on the 1.0 series. The only bugs
marked FIXED with the strings "fast" and "load", and that were resolved after
1.0 was released are bug 151262, bug 142869, and bug 159314. Could the
regression have been introduced in the fixes to one of these bugs?

The duplicate bug with the lowest bug number is bug 167523. It was reported on
September 9th. It looks like bug 159314 was checked in on September 3rd. Seems
suspicious.

Just thinking out loud.
Keywords: regression
Andrew, this bug was introduced by the changes for XUL prototype element
FastLoad (bug 112064, "Fastload XUL documents and elements.").

The reason this bug doesn't show up in Phoenix is because Phoenix has only one
master XUL document, the browser one.  I believe, based on jrgm's great
detective work, that this bug is a result of two .xul files each including a .js
file.  If you start up with N.xul and it includes C.js, then quit; then start up
with M.xul (say, via mozilla -mail) and it includes C.js also, you'll get
assertions in a debug build, and a corrupted FastLoad file that leads directly
to hangs (nearly infinite loops, malloc runaways).

Sorry I didn't catch the bug in reviewing Ben's patch for 112064.  I'm working
on the fix now.

/be
Depends on: 188744
Summary: Corrupted XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs Mozilla/MailNews/etc (when opening Edit > Preferences, or at "random") → Corrupted XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs (not crashes) Mozilla/MailNews/etc (when opening Edit > Preferences, or at "random")
*** Bug 184738 has been marked as a duplicate of this bug. ***
I think I have the same problem (Mozilla 1.2.1, Linux): random crashes, or when
opening Edit->Prefs
Deleting XUL.mfasl seems to solve the problem. (I attached my "buggy" XUL-file)
Sometimes I also had a netstat <defunct>. Any relation to bug 51429???
*** Bug 187675 has been marked as a duplicate of this bug. ***
*** Bug 189511 has been marked as a duplicate of this bug. ***
A fix for bug 188744 was landed Thursday night, and builds after Friday morning
will have had that fix in them.

So, I'm particularly interested in cases where people experience this bug (or
something similar) in builds from Jan 16th onwards. I don't need to see any 
additional fastload files that were generated by builds of Jan 15th and before.
I've filed a followup bug for an additional problem that I noticed, bug 189832.
Depends on: 189832
*** Bug 189934 has been marked as a duplicate of this bug. ***
*** Bug 190004 has been marked as a duplicate of this bug. ***
I'm experiencing the same problem (using v1.2.1) with the XUL.mfl corruption and
moz hanging whenever I chose edit--> pref's.  I changed the file attribute to
"read only", and this seems to have resolved the problem for me so far (without
having to delete it or use a batch file).  I'm just wondering if this is ok, or
does the XUL.mfl file needs to be constantly edited/updated by the application? 
As noted above (comment #137) a fix for this was landed on the trunk (1.3x)
on Thursday night (well, 2am Friday morning, but anyways). I'm interested
in people who have problems with this hang in builds from Jan 17 onwards.

Let's not change this bug into a search for kludgy workarounds and let's not
pretend that 1.2.1 was anything but a milestone along the road.
John, your statement about 1.2.1 just being a milestone, though technically
correct, is only of value for developers as those of us with dozens of desktops
deployed with 1.2.1 have to deal with this!  

Just for clarity, the 1.3beta downloaded and installed yesterday on one of the
problem desktops (W2k) does NOT resolve this matter, so even if we're all
attempting to have a happy 'looking forward' philosophy, we still need pratical
'work-arounds' to keep our user communities funtioning because they CANNOT wait
for perpetual alpha/beta releases that just 'might' address the problem.

Regards,

Barry Treahy
First, let's be clear that the ".1" in 1.2.1 implies nothing about any
special stability, or continued maintenance. That release was made because
1.2 contained a bug due to a completely botched checkin. So this is all
alpha software.

The only mozilla release that has received substantial stabilization,
sustained testing and continued maintenance is mozilla 1.0.2 (which is 
also Netscape 7.01). I, personally speaking, would not recommend that
any of the trunk milestones be deployed for 'dozens of desktops'.

(Actually, I'm kinda happy that people are making broad use of mozilla, so
don't get me wrong. And don't take my general crabiness the wrong way; this
is just a frustrating hide-and-seek bug).

As for setting this readonly, a quick test on win32 shows me that this may 
be okay. But I don't really have time to make a more thorough evaluation. 
And any bugs reported about problems running in that mode will be immediately
invalid.
*** Bug 184534 has been marked as a duplicate of this bug. ***
*** Bug 190163 has been marked as a duplicate of this bug. ***
*** Bug 190230 has been marked as a duplicate of this bug. ***
-> #142
"we still need pratical 'work-arounds' to keep our user communities funtioning"
*Yes*
Some actual hints of the Mozilla homepage would be *very* helpful!

My question: does this work:
-> #126
user_pref("nglayout.debug.disable_xul_cache", true);

or:

Disable XUL-Cache ON (Edit, Prefs, Debug, Networking)
Reply to comment 147 question:

See bug 159364 comment 11 (and previous) if it can help.

> My question: does this work:
> -> #126
> user_pref("nglayout.debug.disable_xul_cache", true);

No, it does not. Do not _ever_ set that pref in a user profile. That pref
should not even exist, and only remains for the benefit of some xul developers.


I've just hit this bug in 1.2.1. It happened when attempting to display
the prefs dialog after the following "less than usual" steps:

1) Clear history
2) Clear location bar
3) Quit Mozilla
4) Restart Mozilla

I got around it by renaming XUL.mfl and letting Mozilla recreate it.  
Do you want another sample corrupted XUL.mfl file?  If so, 
please reply and I will attach it. (What is XUL.mfl used for, BTW?)
> Do you want another sample corrupted XUL.mfl file? 

Thanks, but, I really only now need to see it if this happens in a nightly 
build dated Jan 17 or later.

> (What is XUL.mfl used for, BTW?)

It is a serialized form of the xul and js documents that compose the UI.
> No, it does not. Do not _ever_ set that pref in a user profile. That pref
> should not even exist, and only remains for the benefit of some xul developers.

Well, last week, as soon as I saw comment 126, I added this pref to *all* users
user.js (after testing that indeed it would not use the fastload file) and it
seems not to have caused any problem.
-> comment 149
>> My question: does this work:
>> -> #126
>> user_pref("nglayout.debug.disable_xul_cache", true);

>No, it does not. Do not _ever_ set that pref in a user profile. That pref
>should not even exist, and only remains for the benefit of some xul developers.

I did it a week ago (in prefs.js not user.js): No problems with Mozilla, no
crash, no extensive memory use like before. What is the problem?

Please, what is a recommendable work around? 
* modify the XUL prefs 
* Del XUL.mfl before mozillas start
* Make XUL.mfl readonly
Sorry for asking and thanks a lot. 
*** Bug 190500 has been marked as a duplicate of this bug. ***
*** Bug 187089 has been marked as a duplicate of this bug. ***
*** Bug 190663 has been marked as a duplicate of this bug. ***
Depends on: 184204
Depends on: 179346
Depends on: 168516
*** Bug 187591 has been marked as a duplicate of this bug. ***
*** Bug 188039 has been marked as a duplicate of this bug. ***
*** Bug 188027 has been marked as a duplicate of this bug. ***
*** Bug 190902 has been marked as a duplicate of this bug. ***
*** Bug 191044 has been marked as a duplicate of this bug. ***
*** Bug 191105 has been marked as a duplicate of this bug. ***
*** Bug 191152 has been marked as a duplicate of this bug. ***
Hi, 

Just an update on this bug. I tried using the nglayout.* flags to turn off the
XUL cache. It doesn't seems to be honoured. The file size continues to grow. Tried
changing the file permissions. Still no use. Even changed the ownership to root.
Still the file appears again. (Linux bug?) Only way out was to use the ext2 flag
"immutable" on XUL.mfasl.  Mozilla has been very stable and more responsive ever
since. It's been five days and no crashes so far. 


you can delete the file and re-create it if you have the "write" right
on the directory where the file resides.
permissions/owner of that file itself are of no importance,
and changing the permissions/owner on the directory might not be a good idea :-)
*** Bug 191174 has been marked as a duplicate of this bug. ***
*** Bug 190883 has been marked as a duplicate of this bug. ***
no longer blocking 1.3beta.
Flags: blocking1.3b+ → blocking1.3b-
*** Bug 191269 has been marked as a duplicate of this bug. ***
*** Bug 187985 has been marked as a duplicate of this bug. ***
*** Bug 191320 has been marked as a duplicate of this bug. ***
I landed an additional fix for this in bug 189832. So I'm interested if 
anyone can reproduce this in builds on or after Jan 17, and also in builds
on or after Jan 31. Of course, it usually takes some time before the right
set of circumstances occurs to trigger this bug, so I don't expect an 
immediate resolution. But I think this is fixed (modulo the fact that the
fix in bug 189832 needs to be made smarter).

For a workaround in builds before then, you could consider either setting 
the XUL.mfl (or XUL.mfasl or 'XUL Fastload File' for linux and mac) to be 
readonly, or even to make a directory with that name. But note that I haven't
fully explored the ramifications of doing that.

I will reiterate one thing though.   
  user_pref("nglayout.debug.disable_xul_cache", true);
Do not _ever_ set that pref in an end user profile.



*** Bug 187865 has been marked as a duplicate of this bug. ***
*** Bug 174473 has been marked as a duplicate of this bug. ***
Blocks: 191609
No longer blocks: 191609
*** Bug 191609 has been marked as a duplicate of this bug. ***
*** Bug 187291 has been marked as a duplicate of this bug. ***
*** Bug 178386 has been marked as a duplicate of this bug. ***
*** Bug 187687 has been marked as a duplicate of this bug. ***
*** Bug 183344 has been marked as a duplicate of this bug. ***
*** Bug 190990 has been marked as a duplicate of this bug. ***
*** Bug 191527 has been marked as a duplicate of this bug. ***
> I will reiterate one thing though.   
>   user_pref("nglayout.debug.disable_xul_cache", true);
> Do not _ever_ set that pref in an end user profile.

Why?
It doesn't work or it could cause more grief than it solves?
(I put it on 54 user profiles a couple weeks ago, no complaints since, at least
not for this bug. I had one more case of bug 186295 though).
*** Bug 191748 has been marked as a duplicate of this bug. ***
> ... or it could cause more grief than it solves?

It will cause more grief than it solves. Do not _ever_ set that pref in an end 
user profile. (Although, I'm just gonna remove this anyways so it can't be 
set).
John, don't you want to reassign this bug to you ?
*** Bug 191859 has been marked as a duplicate of this bug. ***
*** Bug 191211 has been marked as a duplicate of this bug. ***
*** Bug 191610 has been marked as a duplicate of this bug. ***
I guess I was trying to pretend that I didn't really own this :-)

-> jrgm
Assignee: varga → jrgm
*** Bug 190883 has been marked as a duplicate of this bug. ***
Yesterday my Mozilla got into a state where "Edit-> Preferences" would hang it
(always - 100% reproducibly). Deleting the mfasl file solved it. I am running
BuildID 2003012513, will try switching to post-Jan 31 later.
Download 1.3 last night on a fresh, new system running W2K, installed browser
only and had problems with the browser locking up and CPU looping at 100% when
attempting to enter Preferences while a page was rendering...

Barry
> Download 1.3 last night...

What is the build id in the titlebar of the application.
Barry responded in email, but my reply was rejected by his mail server. So my 
question is ... Was it the link with the words "Win (11 MB)" on the main page?
If it was that link, then that build does not have the fix for this 
bug.
--------------------------------------------------
Mozilla 1.3 Alpha
  This is our latest alpha, featuring ...
    * Download
          o Win (11 MB)                           <-- this link???
          o MacOS X (18 MB)
          o Linux (13.5 MB) 
    * Release Notes
--------------------------------------------------

Sorry, over zealous anti-spam.  Yes, that is the link but if it isn't the
'latest alpha' as claimed, that should really be clarified...

Barry
well, we live in a jargon filled world... that is the "latest alpha" because
we haven't produced any 1.3a builds since then. We are now in the 1.3b cycle
(a.k.a., "beta" for 1.3), and when this cycle finishes, that link and text will
be updated to point to a release of 1.3b.

But anyways, this bug was in 1.3a, so it's not unexpected that you encountered 
it in the build you downloaded.
*** Bug 192047 has been marked as a duplicate of this bug. ***
*** Bug 191932 has been marked as a duplicate of this bug. ***
*** Bug 192061 has been marked as a duplicate of this bug. ***
Blocks: 187264
Mozilla 2002121215: 1.3.a
Is this related, should I open another bug, or is there another bug already
(didn't see one): In MailNews, clicked to send mail; it hangs running CPU but no
end activity.  Reboot retried twice; same effect.  Renamed xul.mfl and problem
solved.  Had this problem once before on a previous build, but this is the first
time it's happened on 1.3.a.
> Is this related, should I open another bug...

That _is_ _this_ bug.
(jrgm posted comment 201 just while I was reply: here is my message ;->)

Reply to comment 200:

There is at least another bug report about MailNews and XUL.mfl corruption (try
bug 168516 (R.Fixed) which this bug depends on);
the case of failure is known and closely related to this one.

I think jrgm would agree that reports on builds with his recent patches and the
upcoming (I do hope ;-<) v1.3b only are relevent from now on.

Thanks for your confirmation.
No longer blocks: 187264
*** Bug 187264 has been marked as a duplicate of this bug. ***
Yes griffon,

your problem should be reported in this bug. I noticed the same
behaviour on 1.3a both on W2K and Linux.

*** Bug 192265 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 192398 has been marked as a duplicate of this bug. ***
*** Bug 192405 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

I'm hit too now. It started a few weeks ago when printing in MailNews resulted
in freeze of Mozilla. Yesterday I suddenly couldn't open MailNews at all, and
now I discover a lot of other things opening new windows doesn't work (like
Downloads (download manager), Bookmark group of tabs, etc...).

I don't use QuickLaunch and don't remember having made any configuration changes
or other "interresting stuff".

Deleting XUL.MFL resolved the problem. I have made my corrupted XUL.MFL file
available for download at http://www.rockland.dk/XUL.mfl.corrupt .

*** Bug 192407 has been marked as a duplicate of this bug. ***
Here's something which might be a prelude.
When I enter "www.att.net" into the address field, I get an "Alert" pop-up
saying "The document contains no data." This pop-up occurs twice, before the
web page is brought in. I.e., before the images have not finished loaded
when the pop-ups appear.

Deleting XUL.mfl didn't help. Mozilla 1.3 Build 2003021008 still hangs!

Thanks - Art
marking fixed.


--------------------------------------------------------------------------
> Deleting XUL.mfl didn't help.

Then it cannot be this bug.

You're probably seeing bug 192294, although you "helpfully" left out any 
other details like OS in the comment above.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
*** Bug 192732 has been marked as a duplicate of this bug. ***
*** Bug 186557 has been marked as a duplicate of this bug. ***
*** Bug 192714 has been marked as a duplicate of this bug. ***
*** Bug 192909 has been marked as a duplicate of this bug. ***
*** Bug 193231 has been marked as a duplicate of this bug. ***
*** Bug 193237 has been marked as a duplicate of this bug. ***
*** Bug 184091 has been marked as a duplicate of this bug. ***
*** Bug 184794 has been marked as a duplicate of this bug. ***
*** Bug 184815 has been marked as a duplicate of this bug. ***
*** Bug 193617 has been marked as a duplicate of this bug. ***
*** Bug 193717 has been marked as a duplicate of this bug. ***
*** Bug 193957 has been marked as a duplicate of this bug. ***
*** Bug 194122 has been marked as a duplicate of this bug. ***
*** Bug 194137 has been marked as a duplicate of this bug. ***
*** Bug 194152 has been marked as a duplicate of this bug. ***
*** Bug 194253 has been marked as a duplicate of this bug. ***
*** Bug 194361 has been marked as a duplicate of this bug. ***
*** Bug 194443 has been marked as a duplicate of this bug. ***
*** Bug 188833 has been marked as a duplicate of this bug. ***
*** Bug 194895 has been marked as a duplicate of this bug. ***
Mozilla 1.3b
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210

This version of both the browser and mail hangs every time within 5-10 minutes
of loading.

I don't understand this bug reporting page at all unfortunately -but I do no use
the fastload feature and it still hangs/freezes every time.

In addition screen display is wrong for example go to 

wwww.dpreview.com
WOOHOO!! this bug is now officially the most dupped bug in the history of 
bugzilla.mozilla.org. Thanks to everybody that has made this possible by filing 
all those wonderful dups ;-)

Bring on the champange!
Re comment #232: That sounds much like bug 192294. It was fixed shortly after
release of 1.3b. And will probably not happen when you grab a 1.3 final (once
it's out).

> I don't understand this bug reporting page at all

Well, one important thing about it is that only ONE problem should be covered in
each bug report. Other things to know are that you should search carefully for
already reported similar problems and that you should try to reproduce the
problem with a very recent nightly build to make sure the problem is not fixed yet.
The page you mentioned displays ok here. But that's *really* another bug.

*** Bug 195363 has been marked as a duplicate of this bug. ***
*** Bug 195539 has been marked as a duplicate of this bug. ***
*** Bug 195735 has been marked as a duplicate of this bug. ***
*** Bug 195892 has been marked as a duplicate of this bug. ***
*** Bug 195967 has been marked as a duplicate of this bug. ***
*** Bug 195269 has been marked as a duplicate of this bug. ***
*** Bug 191670 has been marked as a duplicate of this bug. ***
*** Bug 196198 has been marked as a duplicate of this bug. ***
*** Bug 195351 has been marked as a duplicate of this bug. ***
*** Bug 196309 has been marked as a duplicate of this bug. ***
*** Bug 190915 has been marked as a duplicate of this bug. ***
*** Bug 196621 has been marked as a duplicate of this bug. ***
*** Bug 196570 has been marked as a duplicate of this bug. ***
*** Bug 179346 has been marked as a duplicate of this bug. ***
*** Bug 197181 has been marked as a duplicate of this bug. ***
*** Bug 197186 has been marked as a duplicate of this bug. ***
*** Bug 197185 has been marked as a duplicate of this bug. ***
NOTE to Bugzilla Hackers!

My bug was one of the many that was deemed a duplicate of this bug.
I searched bugzilla carefully on several occasions for my problem using every
variation of every keyword I could think of. This bug never came up or if it
did, bore no apparent resemblance to my problem. It seems obvious to the average
user that the bugzilla form is mind-boggling and that the bug search function
seems incomplete or broken. Regardless of whether this is merely the fault of us
dumb end-users or not, it seems to me a tragic waste of developer time that so
many needless bug reports are being filed because users like me (who are trying
their best!) cannot find their problem in bugzilla. This bug should prove beyond
any doubt that someone should roll up their sleeves and change bugzilla so that
this happening again is far less likely.

Even if it just meant that bugzilla users were given two different permission
levels: an end-user status or a developer status, where the end-users got a
stripped down bug-report form that was painfully clear and developers could keep
using the same interface, that might drastically improve things. But, it does
seem to me that the bug search is somehow broken, so that would still need to be
addressed.

Thanks
*** Bug 197400 has been marked as a duplicate of this bug. ***
wish to ask this bug gurus to look at
http://bugzilla.mozilla.org/show_bug.cgi?id=196520
and
http://bugzilla.mozilla.org/show_bug.cgi?id=190885
if those may be dups


I agree with Brian W. Carver - Mozilla freezes for me and I filled duplicate,
because search in this case doesn't help me :(

Reply to comment 254:

*(You marked bug 190885 as a duplicate of bug 196520.)
*See my bug 196520 comment 10.

*** Bug 197969 has been marked as a duplicate of this bug. ***
*** Bug 198258 has been marked as a duplicate of this bug. ***
*** Bug 198404 has been marked as a duplicate of this bug. ***
*** Bug 170233 has been marked as a duplicate of this bug. ***
*** Bug 194161 has been marked as a duplicate of this bug. ***
Is there any John Morrison-approved way of getting rid of the XUL.mfl file?
As others have noted too, there does not seem to be any advantage of this
file.  It is named a "fastload" file but in fact it causes only a slowdown,
as it is stored in the user profile and thus has to be synced with the fileserver
on each user logon/logoff (Windows 2000).
I have jumped through various hoops (like deleting all XUL.mfl files on the
server nightly, deleting the file in a logon script) to get rid of it, and would
like to have a preference setting that just drops it, or deletes it internally
in Mozilla at startup and exit.
In the meantime you can continue hunting this bug, for those that want to have
the fastload file...  it would at least solve a bug for many users that don't
need it.
Reply to comment 262:

Keep cool !

Bug 130041 is the one which you need,
NOT the current one (even if the answer is in comment 126 too).

Rob Janssen, check Bug 130041 comment #4 for your answer.  Basically, you just
create a directory with the same name as the XUL file.
*** Bug 199993 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

After briefly using v1.3 and now v1.4a,
let me confirm, as the reporter who started all this,
that it is fixed: no problem so far, at least ;-)
*** Bug 201409 has been marked as a duplicate of this bug. ***
as bug triager: verified fixed (not many new bugs about this)

Thanks John for fixing this bug !

Please open a new bug if you see this with 1.4a or later builds.
Status: RESOLVED → VERIFIED
*** Bug 137405 has been marked as a duplicate of this bug. ***
*** Bug 191560 has been marked as a duplicate of this bug. ***
*** Bug 170088 has been marked as a duplicate of this bug. ***
Definitely not fixed, but worse than ever!

Mozilla 1.5 on Gentoo Linux.

After 10-15 minutes of intensive browsing, moz starts to react slowly and
finally stops responding to mouse or keyboard. It consumes 100 % CPU and needs
to be killed from the command line.

Any attempt to start mozilla immediately gets a SIGSEGV.

After deleting XUL.mfasl, everything is fine again (for the next 10 minutes or
so...).


According Comment #272: Should this bug be reopened ?
Attachment #114077 - Attachment is obsolete: true
Re comment 272 and comment 273:

Egle:
I'd let 'jrgm' decide to reopen or not.

Klaus:
To help decide, can you attach 1+ corrupted file ?

> According Comment #272: Should this bug be reopened ?

definitely no. there are 100+ people in the CC list, consider the amount of
bugspam! Please file a new bug for new problems.
This bug should in no circumstance be reopened.

Anyone who sees a hang, or near-hang, should get stack samples (gdb, or pstack
if it works), and report a new bug.  Treating a symptom by deleting XUL.mfasl
will not help, and does not mean this bug should be reopened.

/be
*** Bug 182370 has been marked as a duplicate of this bug. ***
*** Bug 190440 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: