168516 - hang while sending mail [fixed by deleting fastload file]

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Darin Fisher]

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.

Comment 1

[Darin Fisher]

Attachment: stack trace

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

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did this happen once, or is it reproducable?

Comment 5

[Darin Fisher]

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

Comment 6

[Darin Fisher]

Attachment: stack trace #2

Comment 7

[Darin Fisher]

Attachment: stack trace #3

Comment 8

[Darin Fisher]

Attachment: stack trace #4

Comment 9

[Darin Fisher]

Attachment: stack trace #5

Comment 10

[Darin Fisher]

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

Comment 11

[Darin Fisher]

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)

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[John Morrison]

Not a dup of anything that I know about.

Comment 14

[Darin Fisher]

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

Comment 15

[FZiegler]

Similar/related(?): bug 167523

Comment 16

[Mats Palmgren (inactive)]

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)

Comment 17

[Mats Palmgren (inactive)]

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

Comment 18

[Boris 'pi' Piwinger]

Is bug 172547 a dupe?

pi

Comment 19

[Serge Gautherie (:sgautherie)]

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

Hope this helps.

Comment 20

[FZiegler]

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

Comment 21

[Boris 'pi' Piwinger]

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

Comment 22

[Matthias Versen [:Matti]]

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

Comment 23

[Nicolas Pioch]

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.

Comment 24

[Boris 'pi' Piwinger]

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

pi

Comment 25

[John Morrison]

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

Comment 26

[Dan Kegel]

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

Comment 27

[Dan Kegel]

Attachment: stack traces and bad XUL.mfasl

Comment 28

[R.K.Aa.]

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

Comment 29

[Frank Wein [:mcsmurf]]

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

Comment 30

[R.K.Aa.]

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

Comment 31

[Serge Gautherie (:sgautherie)]

Based on description and comment 11:

This bug should be marked as a duplicate of bug 169777.

Comment 32

[Sam Johnston]

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?

Comment 33

[John Morrison]

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

Comment 34

[John Coonrod]

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

Comment 35

[Stephan Petersen]

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

Comment 36

[Frank Wein [:mcsmurf]]

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

Comment 37

[Didier Gasser Morlay]

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

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We'd like to fix this for 1.3beta.

Comment 39

[John Morrison]

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

Comment 40

[Serge Gautherie (:sgautherie)]

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

Comment 41

[Samir Gehani]

-> jag since this is a 1.3b blocker.

Comment 42

[John Morrison]

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.

Comment 43

[John Morrison]

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