hang in sharable string code while sending mail [linux trunk 2002091108]... attaching a stack trace from this build, which indicates a hang while trying to lock a mutex inside the sharable string code.

fortunately some of the symbols did resolve, but this stack trace probably doesn't help that much.

That's not our lock, that's the libc/libstdc++ allocator's lock. What do the stacks on other threads look like?

(My guess is that the other threads won't be at all interesting, and that this seems more likely to happen because something else stomped on the memory of the lock to make it look like it was held by another thread. Or something fun like that...)

Did this happen once, or is it reproducable?

ok, more information (which i should have gathered before filing this report)... it isn't a deadlock as i originally thought... it's a tight loop inside content (probably) that keeps entering string code. it is very reproducible, and when it happened again, i attached the debugger a couple times to sample the stack... i'll attach the other traces... from the look of things this might even be a fastload bug (i'm going to experiment with moving away my fastload file in a second).

stack trace #4 (attachment 99084 [details]) is the one that implicates fastload.

this hang was 100% reproducible for me until i moved aside my XUL.mfasl ... -> ben (let me know if you want to see my XUL.mfasl file)

jrgm, is this a dup? Darin, did you hang forever with 0% CPU? Or with 100% CPU? How long did you wait before killing the process? Any chance of rerunning with a system call tracer hooked up? /be

Not a dup of anything that I know about.

100% CPU... left it for a minute and it had really chewed up a lot of virtual RAM (major swapping).

Similar/related(?): bug 167523

This problem happened to me too with a 2002-09-27-08 trunk Linux build. Always when I opened the "View Source" window Mozilla hanged with 100% CPU. Renaming "XUL.mfasl" made the problem go away. I still have the file around if you want to have a look at it. (It's ~2.9MB)

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

Is bug 172547 a dupe? pi

Yes, bug 172547 seems to be a dupe; Like this bug, it blocks bug 134576 (meta-bug). Hope this helps.

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

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

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

Experiencing this very issue with Mozilla/1.2.1 on Windows 2000 sp3 and 100% CPU Utilization and memory growing without bounds until I kill the process, along with freezes at splash screen such as bug 167523 with the same CPU Utilization and memory leakage.

Several dupes, many likely dupes not yet identified for sure. That should really be fixed for 1.3.b, requesting blocking. pi

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

Happened to me on Mozilla 1.3alpha on Red Hat 8.0 installed from xft rpms. (Might be a coincidence, but it happened after I turned on my .sig.) Once it started happening, it was 100% repeatable until I renamed XUL.mfasl as suggested. Then problem went away. I'll attach a tgz of some gdb backtraces and the XUL.mfasl. FWIW, I have a couple mail folders with 8000 or so messages and am short on disk space (only 53 MB free in /home).

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

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

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

Based on description and comment 11: This bug should be marked as a duplicate of bug 169777.

We too experienced this problem and believe it to be the result of an unexpected restart which apparently corrupted the XUL.mfl(?) file. Renaming the file resolved the problem immediately. I imagine this one is going to be difficult to fix - is there any way to validate the contents of the file and turf it if corrupt? I don't know what the file does but I imagine it is some sort of cache for the user interface, nor how it is written to. If it's written sequentially then maybe writing the file and moving it over the top of the old file would be a solution?

> We too experienced this problem and believe it to be the result of an > unexpected restart which apparently corrupted the XUL.mfl(?) file. Why do you believe this specifically to be the case? What exactly do you mean by "unexpected restart"? > is there any way to validate the contents of the file and turf it if > corrupt? Actually, we do already perform a number of checks before using the file. We could put in loads of additional failsafe checks when reading that file, but that would somewhat defeat the purpose of the fastload file. Much better to find out what is really going wrong and prevent that from happening on writing the file. > I don't know what the file does but I imagine it is some sort of cache > for the user interface Yes, it is a serialization of the XUL and JS files that are used in the UI. > If it's written sequentially then maybe writing the file and moving it > over the top of the old file would be a solution? No, it's not written sequentially.

I have to say - I cannot notice any difference in load time with and without this file present - my suggested solution is thus to eliminate this feature rather than fix it. I'm always in favor of "simplify, simplify, simplify."

I can comfirm that deleting XUL.mfl also worked for me. I'm using 1.2.1 on W2K with IMAP to access my mail on a Linux server. Since this morning, mozilla would hang when doing things like - sending email (reading was o.k.), - clicking on "view setting for this acocunt" I searched bugzilla, found this entry, deleted XUL.mfl, and it worked immediately. Thank you guys for having such a useful bug reporting/QA system! Stephan

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

I can confirm that this happened to me on 1.2.1 /W2000 SP2. Scenario: I created a new news account, closed the preferences window and when tried to subscribe to newsgroups -> hang with 100% CPU. From then on every time I was trying to send (either a new message or a reply) the same would happen (hang + 100%CPU). I could not go back to the preferences window either (same) I deleted XUL.mfl file as suggested here -> works perfectly well now. I also have not notices any performance issues since that file was deleted. (Note: the XUL was over 2.7Mb which seems large for a speed-up trick) Thanks for all your work guys! Didier

We'd like to fix this for 1.3beta.

This may be fixed by bug 188744's fix. I'm waiting for someone to demonstrate that this hang can be reproduced in a trunk build from Jan 17 onward. (And if you see this hang, darin, please try to find me so I can look at in the debugger. Thanks).

Following comment 31, I add a dependency, as this bug was not marked as duplicate.

-> jag since this is a 1.3b blocker.

This is really just a dup of bug 188744, and I believe it is fixed in trunk builds after Jan 17th. But, if not fixed yet, I have another patch to land tonight that will probably complete the fix, at least for now.

Hmm, that was suppose to be duped to 188744, but anyways...