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.

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

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

Oliver: if you hang with a debug build, you can attach gdb (on Linux) and grab a stacktrace: % gdb mozilla-bin (pid-of-mozilla)

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

-> kmcclusk for triage.

-> Alex

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

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.

->Style System (for analysis, anyway)

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

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

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

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

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

Comment on attachment 118922 [details] [diff] [review] Somewhat like this David? What do you think?

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.

Checked in.

Verified fixed on supplied URL.