Bug 4076 – [INTERPRETER] Loading www.fed-soc.org causes hang (eventually finishes)

• Component: JavaScriptCore
• Status: RESOLVED INVALID

[Jon]

When attempting to load fed-soc.org with TOT WebKit based Safari, Safari beachballs while loading the 
page. Content is rendered, but the progress bar and spinner never complete and Safari uses 100% of the 
CPU (500 MHz iBook). Only recourse is to force quit Safari.

[Jon]

Tested in Safari 412.2, same result.

[David Storey]

Similar results in V312, but it eventually recovers from spinning pizza, so does not crash (1.25 alu 
powerbook).  Hang lasts about 20 seconds.  

[Stuart Morgan]

Created attachment 3736 [details]
Sample during spin, 9/2 ToT

It eventually completes with 9/2 ToT, but does spin for a while.  Sample
attached.  It's slow in Camino as well, but not nearly this slow.

[Michael J. Cohen]

reproduceable, however, the spinner completes and the site is usable for me.

[Sören Kuklau]

The most likely cause, AFAICT is the huge (1050x1000) background image, http://www.fed-soc.org/images/madisonbackground.gif. I can reproduce this both on 2.0.3 and on r12479.

The loading *does* complete, even on my G3/700 iBook. It just takes a lot of time, and Safari is hanging/unresponsive (including beachball) during it.

[Joost de Valk (AlthA)]

Reassigning to webkit-unassigned, to make sure more people see this.

[Joost de Valk (AlthA)]

Confirmed.

[David Kilzer (:ddkilzer)]

Moving to "New Bugs" from "WebSite" since the latter is used for webkit.opendarwin.org.

The background image mentioned in Comment #5 is only 9 KB (although the authors of this site really need to learn how to use CSS).  This issue needs to be reduced to find the actual cause, so adding NeedsReduction keyword.

The source appears to have Dreamweaver JavaScript functions, so beware!

[David Kilzer (:ddkilzer)]

A quick Shark Time Profile of the Safari while the page is beach-balling shows that most of the time is spent in KJS.  Therefore, moving this bug to the JavaScript component.  It still needs a reduction, though.

[David Kilzer (:ddkilzer)]

I think ggaren would be interested in this bug since it deals with JavaScript and performance issues.  Adding him to CC list.

[Geoffrey Garen]

This looks like the oft-reported bug that JavaScript execution freezes the browser. We have plans to fix this with "tree code."

[Geoffrey Garen]

The other issue here is that a for loop is getting a value from a DOM node, and each get causes a re-layout.

In tree view, you can see that "KJS::DOMNode::getValueProperty(KJS::ExecState*, int) const" calls "DOM::DocumentImpl::updateLayoutIgnorePendingStylesheets()." In heavy view, you can see that the heaviest function calls are all layout calls:

        327      khtml::RenderObject::updateWidgetPositions()
        26       DOM::ElementImpl::recalcStyle(DOM::NodeImpl::StyleChange)
        26       khtml::RenderBlock::lowestPosition(bool, bool) const
        25       khtml::RenderLayer::updateLayerPositions(bool, bool)
        22       khtml::RenderBlock::rightmostPosition(bool, bool) const
        20       khtml::RenderLayer::computeRepaintRects()
        19       khtml::RenderBox::computeAbsoluteRepaintRect(QRect&, bool)
        18       khtml::RenderFlow::lowestPosition(bool, bool) const
        15       khtml::RenderBlock::layoutBlock(bool)
        15       khtml::RenderFlow::rightmostPosition(bool, bool) const
        13       khtml::RenderBlock::getAbsoluteRepaintRectIncludingFloats(QRect&, QRect&)
        13       khtml::RenderFlow::getAbsoluteRepaintRect()
        12       khtml::RenderBox::getAbsoluteRepaintRect()
        12       khtml::RenderObject::isFloatingOrPositioned() const

I'd love to see a reduction that showed what kind of JavaScript get caused this re-layout. Looks like it's something in one of the inline <script> tags. One approach would be to set a breakpoint on DocumentImpl::updateLayoutIgnorePendingStylesheets and get information from the calling stack frame.

[Ingo Chao]

Created attachment 7047 [details]
Reduction

Reduction. These scripts for a complex 4-level flyout menu consume most of the 
time. 

Rendering of the page (approx. time in seconds, iMac 1.9GHzG5 1.5GB):

Fx1.5.0.1 : IE5.2Mac : Opera8.51 : Webkit r13265

4 : 5 : 9 : 28

I used base to reproduce this problem. When I download the scripts, remove the base and open the page locally, there is no problem with that page. Hope this helps.

[David Kilzer (:ddkilzer)]

Created attachment 12260 [details]
Gzipped webarchive of page on 2007/01/06

[David Kilzer (:ddkilzer)]

As of WebKit r18639, the menu on the fed-soc.org web site is misplaced.  See Bug 12141 for details.

[Jon]

Although the website has been update to be much more modern, the webarchive David attached still causes a beachball, even with Safari 4.0.3 on Leopard/PPC with a Quad G5. I'm just going through my old bugs and wanted to bump this and see whether it's still something to be fixed.

[Gavin Barraclough]

The attached webarchive opens nice & quick for me on Safari 5.0.  Based on the bug# I guess this bug is archaic, but please reopen if the issue still repros for you.

[Jon]

Not that quick for me, even on an i7 iMac and it's still slow enough on my Quad G5 to cause the beach ball for a few seconds before loading completes. Even my iMac takes a few seconds to open it, though not enough to cause the beach ball. I don't know if even the lowest Intel Mac would produce the beach ball but like I said, my Quad G5 certainly does.

[Jon]

Takes my i7 iMac approximately 3 - 4 seconds to open the archive, with the Quad G5 taking 10 seconds. JS issue I'd say, since that's the biggest difference between PPC and Intel WebKit, AFAIK.

[Gavin Barraclough]

:-(
10s is certainly an improvement from 28s, but I guess I can't call this fixed, so reopening.

Retitling to reflect that this appears to be an interpreter-related issue.

[Jon]

My brief sampling gives the following as the hottest part: 


	0.0%	74.4%	JavaScriptCore	                           JSC::Interpreter::privateExecute(JSC::Interpreter::ExecutionFlag, JSC::RegisterFile*, JSC::ExecState*, JSC::JSValue*)
	0.0%	32.3%	WebCore	                            WebCore::jsElementOffsetHeight(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
	0.0%	26.3%	WebCore	                            WebCore::jsElementOffsetWidth(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
	0.0%	8.2%	WebCore	                            WebCore::jsElementOffsetLeft(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
	0.0%	6.4%	WebCore	                            WebCore::jsElementOffsetTop(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
	0.0%	0.8%	WebCore	                            WebCore::JSCSSStyleDeclaration::put(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::PutPropertySlot&)
	0.2%	0.2%	JavaScriptCore	                            JSC::Interpreter::privateExecute(JSC::Interpreter::ExecutionFlag, JSC::RegisterFile*, JSC::ExecState*, JSC::JSValue*)
	0.0%	0.1%	WebCore	                            WebCore::jsElementStyle(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
	0.0%	0.1%	JavaScriptCore	                            JSC::jsTypeStringForValue(JSC::ExecState*, JSC::JSValue)
	0.0%	0.0%	JavaScriptCore	                            JSC::JSValue::get(JSC::ExecState*, JSC::Identifier const&, JSC::PropertySlot&) const
	0.0%	0.0%	JavaScriptCore	                            WTF::tryFastRealloc(void*, unsigned long)

[Jon]

Menu is still misplaced as well, as noted by David in #15.

[Geoffrey Garen]

    0.0%    32.3%    WebCore                                WebCore::jsElementOffsetHeight(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
    0.0%    26.3%    WebCore                                WebCore::jsElementOffsetWidth(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
    0.0%    8.2%    WebCore                                WebCore::jsElementOffsetLeft(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
    0.0%    6.4%    WebCore                                WebCore::jsElementOffsetTop(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&)
    0.0%    0.8%    WebCore                                WebCore::JSCSSStyleDeclaration::put(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::PutPropertySlot&)

Seems that my 2006 comment identifying possibly n^2 layout behavior may still be apt.

[Gavin Barraclough]

This bug was interpreter only, the classic interpreter has now been removed from the tree.