285449 - Mozilla frozen at 100%CPU when trying to open message filters window

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[Bertram Franz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050309
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050309

Happens only in self-compiled version, not in the downloaded binary.

(in Mail window) Tools->Message Filters ... will immediately lock up the
complete Mozilla process, sucking up one CPU completely (second CPU idle). Same
happens from the context-menu "Create Filter from Message ...".

my .mozconfig:
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objects
mk_add_options MOZ_CO_PROJECT=suite

ac_add_options --enable-application=suite
ac_add_options --enable-optimize
ac_add_options --disable-freetype2
ac_add_options --enable-xft
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --disable-debug
ac_add_options --disable-tests

Not sure if that is right here in the build config bucket ... Is there some
conflict in any of the above options?

Reproducible: Always

Steps to Reproduce:
1.Open mailer
2.Tools->Message Filters ...

Actual Results:  
no window refresh anymore, no nothing will happen inside any Mozilla window


Expected Results:  
show the Message Filters window

My system (both for build and run):

SuSE 9.2

atk-1.6.0-4
atk-1.9.0-1
atk-devel-1.6.0-4.1
glib-1.2.10-589
glib-2.6.1-1
glib-devel-1.2.10-589
glib2-2.4.6-5
glib2-devel-2.4.6-5
glibc-2.3.3-118
glibc-devel-2.3.3-118
gtk-1.2.10-882.1
gtk-devel-1.2.10-882.1
gtk2-2.4.9-10.1
gtk2-devel-2.4.9-10.1
jpeg-6b-736
libjpeg-6.2.0-736
libjpeg-devel-6.2.0-2
libpng-1.2.6-4
libpng-1.2.8-1
libpng-devel-1.2.6-4
libtiff-3.6.1-47.4
libtiff-devel-3.6.1-47.4
pango-1.4.1-3
pango-1.8.0-1
pango-devel-1.4.1-3.1
pkgconfig-0.15.0-199
tiff-3.6.1-47.4

Comment 1

[Bertram Franz]

Attachment: about:buildconfig

Comment 2

[R.K.Aa.]

Does the freeze occure with a default theme?

Comment 3

[R.K.Aa.]

Did you clobber or at least delete compreg.dat before starting the app?
Asking in order to eliminate user error and/or profile corruption

Comment 4

[Bertram Franz]

(In reply to comment #3)
> Did you clobber or at least delete compreg.dat before starting the app?
> Asking in order to eliminate user error and/or profile corruption

The build tree was completely clean (just downloaded the source, unpack, copy in
my .mozconfig, start the build)
The freeze also happens, when directly running mozilla/<MOZ_OBJDIR>/dist/bin/mozilla

This is with the default theme.

I have a .mozilla/firefox/mfjero0s.default/compreg.dat which is different from
the built one (but is probably not used for mozilla?)

The downloaded compreg.dat is also quite different than what I've built ...

Comment 5

[R.K.Aa.]

compreg.dat isnt buildt, it's generated on first startup
Can you try this: Quit mozilla, delete compreg.dat (in the mozilla dir) then
restart. Still no go?

If the freeze still happens: Please also try with a brand new profile

Comment 6

[Bertram Franz]

(In reply to comment #5)
> compreg.dat isnt buildt, it's generated on first startup
> Can you try this: Quit mozilla, delete compreg.dat (in the mozilla dir) then
> restart. Still no go?

Still the same. And the new compreg.dat is identical.

> If the freeze still happens: Please also try with a brand new profile

Ahh, this works well !!! So there's just something in my profile (my existing
filter settings?). Strange that the "official" build can handle it ...

Is there any debug option or alike that I can see what exactly causes the
trouble? I would like to keep a few settings at least ...

Comment 7

[R.K.Aa.]

Can you try this:
quit moz, rename XUL.mfasl in your old profile dir 
(mv XUL.mfasl XUL.mfasl.suspect), then restart with old profile.
Still the same hang?

Comment 8

[Bertram Franz]

(In reply to comment #7)

Yes. Still the same hang. (The newly created XUL.mfasl is much smaller though.)

Comment 9

[Andrew Schultz]

your build config is fine...

==> filters

Comment 10

[Andrew Schultz]

Bertram: can you try to migrate your real profile into the clean one?  (copy
files) until the clean one also has the problem?

and/or can you grab a stracktrace with gdb?

% mozilla -g -d gdb
[make Mozilla hang]
[hit Ctrl-C]
(gdb) bt
[copy the stacktrace to a file and attach it to this bug]

Comment 11

[Bertram Franz]

Attachment: stacktrace of spinning mozilla

As the process was spinning recursively, I cut out a few thousand lines of the
stack.

Comment 12

[David :Bienvenu]

I've seen a bug with similar stacks before, but I thought that bug was fixed.
Have you tried removing localstore.rdf? What date did you get the source?

Comment 13

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

Either a tree or listbox is calling PresShell::PostReflowCallback every time it
reflows. Which one would it be?

Comment 14

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

It would be useful to run the app, let it spin for a while, then put a
breakpoint on PresShell::PostReflowCallback, run to the breakpoint, and get a
stack trace.

Comment 15

[Bertram Franz]

The last download was done 2005-03-09 13:27.

I just now downloaded and compiled the 03-21 code, with the same results.

I got the stacktrace out of the breakpoint as requested and will attach it.

Thanks for your continued help
Bertram

Comment 16

[Bertram Franz]

Attachment: stacktrace from PresShell::PostReflowCallback

Comment 17

[Bertram Franz]

Attachment: localstore.rdf causing the hang

Sorry for not testing that earlier: removing my localstore.rdf cures the
problem.
I've attached my original one, with just a few history links deleted (the
problem is still reproducible with that one).

Comment 18

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

That's here:
http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsListBoxLayout.cpp#254

Bertram, could you grab some more traces of PostReflowCallback and see if any of
them are elsewhere?

Comment 19

[Bertram Franz]

(In reply to comment #18)
> That's here:
> http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsListBoxLayout.cpp#254
> 
> Bertram, could you grab some more traces of PostReflowCallback and see if any of
> them are elsewhere?

I took 5 more stacks, except for the addresses and the depth of the stack they
are identical.

You've made me curious, and I've now built a debug version, also with
--enable-tests. Immediately before the hang I see on the console:

Trying to position a sizeless window; caller should have called sizeToContent()
or sizeTo(). See bug 75649.

Debugging further, I've seen that availableHeight is set to 3951 in line 183,
yOffset stays 0. These values don't change over all the iterations (OK, at least
over 2 iterations).

Therefore the return in line 191 is never reached.

Does this help somehow?

Comment 20

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

That's very helpful. can you let it spin again and then break in CreateRows, get
a stack trace, and tell me what happens when you step through it?

Also it'd be useful to know what happens during nsListBoxLayout::LayoutInternal,
why yOffset doesn't change. Are there no box children, or are they all height 0?

Comment 21

[Bertram Franz]

I was a little wrong in comment #19.

inside the while (box) loop of nsListBoxLayout::LayoutInternal,
yoffset increases by 468 each loop, and availableHeight starts from 3717 or 3951
(alternating twice each) and decreases until it is -27, or sometimes -495
(second time negative, after -27) and -261 for the 3951 height.

The problem rather seems to be that in nsGfxScrollFrame.cpp:2025, needsLayout is
always true, because it is set in nsGfxScrollFrame.cpp:1991 and 2018 (strictly
alternating sequence).

Comment 22

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

My guess is it's something like this...

1) We reflow the listbox. It gets N list items. The last list item causes
horizontal overflow. So we add a horizontal scrollbar and reflow the listbox
again. In the post-reflow callback, in nsListBoxBodyFrame::ContinueReflow, the
listbox notices that it can't fit the last item anymore, nukes it, and marks
itself dirty.

2) So we reflow again. This time there is a horizontal scrollbar and only N-1
items fit. No horizontal scrollbar is needed, so the scrollframe removes it and
re-reflows the listbox. The listbox notices that it has space left over for
another item and marks itself dirty for another reflow. We go back to step 1.

One question I have is why we even allow a horizontal scrollbar on XUL
listboxes. Does anyone use it?

Comment 23

[[e-mail]]

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

Comment 24

[[e-mail]]

(In reply to comment #22)
>My guess is it's something like this...
This matches up with my experience in my duplicate.

>One question I have is why we even allow a horizontal scrollbar on XUL
>listboxes. Does anyone use it?
The Suite's search sidebar tries to use a horizontal scrollbar but the painting
is somewhat erratic as the listitems appear to use the width of the listbox and
the listcells that do overflow will only paint if the listitem is visible (i.e.
not scrolled too far left).

Comment 25

[[e-mail]]

Attachment: Proposed patch

Comment 26

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

Comment on attachment 180573 [details] [diff] [review]
Proposed patch

please also add "overflow-x:hidden !important" with a comment pointing to this
bug

Comment 27

[[e-mail]]

Comment on attachment 180573 [details] [diff] [review]
Proposed patch

For check in to both versions of xul.css with roc's review nit.

Comment 28

[Asa Dotzler [:asa]]

Comment on attachment 180573 [details] [diff] [review]
Proposed patch

a=asa

Comment 29

[[e-mail]]

Fix checked in.