166205 - [FIX]CSS rules cause Mozilla to hang [@ nsFrame::GetView]

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Laurens van der Starre]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826

http://virtuafighter.com/view.php?section=vf4&file=vf4_items_faq_wayne.txt
causes Mozilla to lock up (Mozilla crashes). At first everything looks normal,
Mozilla says "document don: x sec" but actually the browser locked up. The
Windows XP taskmanager cannot close Mozilla. Only after a couple of times
clicking on "end task" Mozilla closes. 

The URL is some PHP generated page, which text comes from some sort of text file.

I use Mozilla 1.1 . Mozilla 1.1a and 1.1b and also the 1.0 versions have the
same problem.

System info:
Windows XP
Athlon Thunderbird 1Ghz, 512MB RAM, GForce2GTS, SB Live.

Reproducible: Always

Steps to Reproduce:
1. Simply go to:
http://virtuafighter.com/view.php?section=vf4&file=vf4_items_faq_wayne.txt
Actual Results:  
Mozilla crashes.
(Actually, I performed the test just before writing the bugreport: didn't want
to type it all over again :-) )

Expected Results:  
Displaying the page of the Virtua Fighter 4 Item FAQ, without crashing. Like IE
does (and Opera).

I use the default theme. 
Mozilla Mail was also running. Seems that Mail crashes first: Mail's window
becomes totally white, Browser window stays normal. At least, the last time I
reproduced the crash it did. I don't know if this is always the case, haven't
paid attention to it.

Comment 1

[Olivier Cahagne]

confirming hang using build 2002090204 on Win2k (trunk), CPU stuck at 99%.

Laurens, did you get a Talkback window popup when crashing ? If so, please post
Talkback ID 'mozilla/bin/components/talkback.exe'.

Comment 2

[Olivier Cahagne]

also hang build 20020901 on Linux (trunk), CPU 99%. In debug mode, no special
warning or error (besides CSS parsing errors).

Comment 3

[Andrew Schultz]

Oliver: if you hang with a debug build, you can attach gdb (on Linux) and grab a
stacktrace:

% gdb mozilla-bin (pid-of-mozilla)

Comment 4

[Matthias Versen [:Matti]]

nsFrame::GetView(const nsFrame * const 0x03d4bba0, nsIPresContext * 0x048340e0,
nsIView * * 0x0012e8cc) line 2053
nsFrame::GetOffsetFromView(const nsFrame * const 0x05b2d2cc, nsIPresContext *
0x048340e0, nsPoint & {...}, nsIView * * 0x0012e8cc) line 2168
DoApplyRenderingChangeToTree(nsIPresContext * 0x048340e0, nsIFrame * 0x05b2d2cc,
nsIViewManager * 0x0484b638) line 10090
ApplyRenderingChangeToTree(nsIPresContext * 0x048340e0, nsIFrame * 0x05a79a4c,
nsIViewManager * 0x00000000) line 10157 + 22 bytes
nsCSSFrameConstructor::ProcessRestyledFrames(nsCSSFrameConstructor * const
0x0473f918, nsStyleChangeList & {...}, nsIPresContext * 0x048340e0) line 10328 +
15 bytes
nsCSSFrameConstructor::ContentStatesChanged(nsCSSFrameConstructor * const
0x0473f918, nsIPresContext * 0x048340e0, nsIContent * 0x04761fb0, nsIContent *
0x00000000, int 4) line 10485
StyleSetImpl::ContentStatesChanged(StyleSetImpl * const 0x0473f750,
nsIPresContext * 0x048340e0, nsIContent * 0x04761fb0, nsIContent * 0x00000000,
int 4) line 1575
PresShell::ContentStatesChanged(PresShell * const 0x04b24148, nsIDocument *
0x0476cd10, nsIContent * 0x04761fb0, nsIContent * 0x00000000, int 4) line 5182 +
53 bytes
nsDocument::ContentStatesChanged(nsDocument * const 0x0476cd10, nsIContent *
0x04761fb0, nsIContent * 0x00000000, int 4) line 2098
nsEventStateManager::SetContentState(nsEventStateManager * const 0x0473d708,
nsIContent * 0x04762170, int 4) line 3811
nsEventStateManager::GenerateMouseEnterExit(nsIPresContext * 0x048340e0,
nsGUIEvent * 0x0012f8a4) line 2380
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x0473d708,
nsIPresContext * 0x048340e0, nsEvent * 0x0012f8a4, nsIFrame * 0x04ac6234,
nsEventStatus * 0x0012f69c, nsIView * 0x04ba79f0) line 394
PresShell::HandleEventInternal(nsEvent * 0x0012f8a4, nsIView * 0x04ba79f0,
unsigned int 1, nsEventStatus * 0x0012f69c) line 6099 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x04b24144, nsIView * 0x04ba79f0,
nsGUIEvent * 0x0012f8a4, nsEventStatus * 0x0012f69c, int 0, int & 1) line 6028 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x04ba7770, nsGUIEvent * 0x0012f8a4, int 0)
line 2092
nsView::HandleEvent(nsViewManager * 0x0484b638, nsGUIEvent * 0x0012f8a4, int 0)
line 301
nsViewManager::DispatchEvent(nsViewManager * const 0x0484b638, nsGUIEvent *
0x0012f8a4, nsEventStatus * 0x0012f7a0) line 1897 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f8a4) line 83
nsWindow::DispatchEvent(nsWindow * const 0x04ba782c, nsGUIEvent * 0x0012f8a4,
nsEventStatus & nsEventStatus_eIgnore) line 1034 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8a4) line 1055
nsWindow::DispatchMouseEvent(unsigned int 300, unsigned int 0, nsPoint *
0x00000000) line 5125 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, unsigned int 0, nsPoint *
0x00000000) line 5382
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 14222054, long *
0x0012fcf0) line 3833 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x00cc047e, unsigned int 512, unsigned int 0, long
14222054) line 1303 + 27 bytes
USER32! 77e01d0a()
USER32! 77e01bc8()
USER32! 77e072b4()
nsAppShellService::Run(nsAppShellService * const 0x03a602d8) line 472
main1(int 2, char * * 0x00283160, nsISupports * 0x00000000) line 1513 + 32 bytes
main(int 2, char * * 0x00283160) line 1877 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8ca90()

-> Layout

Comment 5

[greer]

-> kmcclusk for triage.

Comment 6

[Kevin McCluskey (gone)]

-> Alex

Comment 7

[Alexandru Savulov]

hmmm, i don't see a crash but i do see the hang. not every time though.

Comment 8

[Michal Kluka]

This is not hang, this is performance problem. In reference css there is:


A:hover {


	COLOR: #ffffff; TEXT-DECORATION: none


}


A.nav:hover {


	COLOR: #ffffff; TEXT-DECORATION: none


}


A.navhdr:hover {


	COLOR: #ffffff; TEXT-DECORATION: none


}


A:active {


	COLOR: red


}


A.nav:active {


	COLOR: red


}


A.navhdr:active {


	COLOR: red


}


If you move cursor over the text, mozilla will change color of the text. Problem 
is it takes way too much time. If you leave cursor out of text area than CPU 
utilization will drop to zero after 5 minutes ( depends on CPU speed ). If you 
download this page using IE, you can cat the "text" to "resonable" size and than 
you can even see mozilla working.

Comment 9

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

->Style System (for analysis, anyway)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: non-realtime jprof of hovering over the text once

So why are we spending so much time in DoApplyRenderingChangeToTree?  This
smells of a O(N^2) algorithm somewhere....

Comment 11

[Boris Zbarsky [:bzbarsky]]

So the problem is that FrameManager::ComputeStyleChangeFor will put all the
in-flows of the frame in the changelist.  Then when we go to
ApplyRenderingChangeToTree, we walk the in-flows for every frame in the list. 
So the whole repaint is O(N^2) in number of in-flows.  With a huge <pre> like on
that page, there are a _lot_ of in-flows....

Looking at nsCSSFrameConstructor::ProcessRestyledFrames, the reframe and repaint
codepaths handle in-flows on their own.  Does the reflow path do it?  (it's not
as obvious with that one, but I'd think it does).

If so, we can just change FrameManager::ComputeStyleChangeFor to properly set
the min hint in such a way that the in-flows don't end up in the list....

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Somewhat like this

This patch makes the page in question much faster (1-2 secs to update instead
of minutes, all wall clock time).

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: reflow testcase

This exercises the IB code too, not just the nif code.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I'm pretty confident that this is the right approach....

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 118922 [details] [diff] [review]
Somewhat like this

David?	What do you think?

Comment 16

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

Comment on attachment 118922 [details] [diff] [review]
Somewhat like this

I don't understand this at the moment, so if you're confident I'll trust you.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 18

[Adam D. Moss]

Verified fixed on supplied URL.