118566 - Preferences window freezes for ~10 seconds whilst navigating treeview

Status: RESOLVED WORKSFORME

(SeaMonkey :: Preferences, defect)

Description

[Matthew Russell]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020104
BuildID:    2002010421

Whilst opening and closing sections in the preferences dialog, Mozilla will
suddenly freeze for around 10 seconds before recovering.

Reproducible: Always
Steps to Reproduce:
1. Open prefs dialog
2. Expand the menu tree, starting with 'Appearance' and finishing with 'Debug'
3. Close up the tree again, working upwards, starting with 'Debug'.


Actual Results:  Mozilla freezes for a time whilst closing up the tree, at the
"Privacy and Security" option, but occasionally elsewhere.

Expected Results:  Mozilla should have no perceptible delay whilst opening and
closing these menus.

Comment 1

[Mauricio Collares [:collares]]

WFM, Linux CVS build 2002010607

Comment 2

[Daniel Brooks [:db48x]]

WFM 2002010608 WinNT4

Comment 3

[Mauricio Collares [:collares]]

sorry, forgot to reassign

Comment 4

[Erik Hensema]

Confirming, Linux 2002010708.

This must be related to bug 59108. Reassign to owner.

Mozilla goes to 100% CPU for maybe half a minute on my system (AMD K6-2 300 Mhz).

This is a backtrace from the thread getting all the CPU:

#0  0x4103cfd2 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgklayout.so
#1  0x4102f9c3 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgklayout.so
#2  0x4102f39e in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgklayout.so
#3  0x4102eb9b in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgklayout.so
#4  0x40f472d8 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgklayout.so
#5  0x40bd9f47 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgkview.so
#6  0x40be2047 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgkview.so
#7  0x40be1e52 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgkview.so
#8  0x40be0d96 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgkview.so
#9  0x40be334a in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgkview.so
#10 0x40bd9b2d in NSGetModule ()
   from /home/erik/moz/mozilla/components/libgkview.so
#11 0x40c02a6a in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#12 0x40c02995 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#13 0x40c05909 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#14 0x40c05a09 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#15 0x40c05b6c in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#16 0x40c057bd in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#17 0x403a8d4f in g_idle_dispatch (source_data=0x40c05760,
    dispatch_time=0xbffff254, user_data=0x0) at gmain.c:1367
#18 0x403a7c46 in g_main_dispatch (dispatch_time=0xbffff254) at gmain.c:656
#19 0x403a8273 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#20 0x403a843c in g_main_run (loop=0x81fe188) at gmain.c:935
#21 0x402b4dec in gtk_main () at gtkmain.c:524
#22 0x40bf7614 in NSGetModule ()
   from /home/erik/moz/mozilla/components/libwidget_gtk.so
#23 0x4127af2e in nslberi_memalloc_fns ()
   from /home/erik/moz/mozilla/components/libnsappshell.so
#24 0x8050099 in _start ()
#25 0x8050907 in main ()
#26 0x404f0baf in __libc_start_main () from /lib/libc.so.6

Comment 5

[Jan Varga [:janv]]

WFM

Comment 6

[sairuh (rarely reading bugmail)]

confirming --i've encountered this twice today... unfortunately, i'm still
trying to narrow down a specific set of steps to repro this. methinks it'll only
occur the first time you bring up prefs during a session...

Comment 7

[Jan Varga [:janv]]

then, it might be related to bryner's changes to pref size

Comment 8

[Matthew Russell]

Attachment: naive fix

This seems to fix this bug, but I suspect it's not the correct way - I'm a
newcomer to the Mozilla code.

Comment 9

[Jan Varga [:janv]]

I'm still not able to reproduce it.

Comment 10

[Jan Varga [:janv]]

Are you guys using own build or nightly and which OS?

Comment 11

[Olav Vitters]

I can reproduce this on 2002010908, Linux.

Hangs every time when I close the Composer tree. When I make the preferences
window bigger, it hangs at 'Privacy and Security' (at 800x600). 

Comment 12

[Erik Hensema]

Confirming, Linux 2002010908. Simply expand the entre preferences tree and
collapse it again: I get a hang (100% CPU) for about half a minute.

Comment 13

[Matthew Russell]

I compiled from CVS, and when the prefs froze, the following error message was
dumped to the console thousands of times:

###!!! Break: at file nsOutlinerContentView.cpp, line 378
###!!! ASSERTION: bad row index: 'aRowIndex >= 0 && aRowIndex < mRows.Count()',
file nsOutlinerContentView.cpp, line 378

Using gdb, it seemed that nsOutlinerContentView::GetParentIndex() was being
called with a negative argument. I think this negative argument was also causing
the for loop in nsOutlinerBodyFrame::PaintCell() to iterate a large number of
times, causing the dialog to hang. I tracked the negative argument to a call to
GetMaxPosition() in nsSliderFrame::AttributeChanged(), hence the patch, but I
really don't know at what point a negative value is an error.

Comment 14

[Jan Varga [:janv]]

Mattew, could you update your tree to the tip ?
I just landed a fix for these assertions today.
But wait until tree opens, since there is a quite annoying blocker.

Comment 15

[Jan Varga [:janv]]

Is somebody still seeing this ?

Comment 16

[Jan Varga [:janv]]

Marking WFM for now.
Feel free to reopen.

Comment 17

[Erik Hensema]

I do not see the bug anymore in 2002012821/Linux.