Bug 4076 - [INTERPRETER] Loading www.fed-soc.org causes hang (eventually finishes)
Summary: [INTERPRETER] Loading www.fed-soc.org causes hang (eventually finishes)
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.fed-soc.org
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2005-07-19 18:58 PDT by Jon
Modified: 2012-09-25 13:51 PDT (History)
6 users (show)

See Also:


Attachments
Sample during spin, 9/2 ToT (301.93 KB, text/plain)
2005-09-03 17:45 PDT, Stuart Morgan
no flags Details
Reduction (666 bytes, text/html)
2006-03-13 07:20 PST, Ingo Chao
no flags Details
Gzipped webarchive of page on 2007/01/06 (486.41 KB, application/x-gzip)
2007-01-06 11:44 PST, David Kilzer (:ddkilzer)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jon 2005-07-19 18:58:00 PDT
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.
Comment 1 Jon 2005-07-19 19:02:54 PDT
Tested in Safari 412.2, same result.
Comment 2 David Storey 2005-07-21 03:53:16 PDT
Similar results in V312, but it eventually recovers from spinning pizza, so does not crash (1.25 alu 
powerbook).  Hang lasts about 20 seconds.  
Comment 3 Stuart Morgan 2005-09-03 17:45:28 PDT
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.
Comment 4 Michael J. Cohen 2006-01-10 09:06:35 PST
reproduceable, however, the spinner completes and the site is usable for me.
Comment 5 Sören Kuklau 2006-02-02 02:22:30 PST
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.
Comment 6 Joost de Valk (AlthA) 2006-02-13 15:55:04 PST
Reassigning to webkit-unassigned, to make sure more people see this.
Comment 7 Joost de Valk (AlthA) 2006-02-15 14:36:31 PST
Confirmed.
Comment 8 David Kilzer (:ddkilzer) 2006-02-26 07:29:19 PST
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!
Comment 9 David Kilzer (:ddkilzer) 2006-02-26 07:58:37 PST
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.
Comment 10 David Kilzer (:ddkilzer) 2006-02-26 09:42:44 PST
I think ggaren would be interested in this bug since it deals with JavaScript and performance issues.  Adding him to CC list.
Comment 11 Geoffrey Garen 2006-02-27 09:39:22 PST
This looks like the oft-reported bug that JavaScript execution freezes the browser. We have plans to fix this with "tree code."
Comment 12 Geoffrey Garen 2006-02-27 09:47:16 PST
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.
Comment 13 Ingo Chao 2006-03-13 07:20:41 PST
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.
Comment 14 David Kilzer (:ddkilzer) 2007-01-06 11:44:57 PST
Created attachment 12260 [details]
Gzipped webarchive of page on 2007/01/06
Comment 15 David Kilzer (:ddkilzer) 2007-01-06 11:51:08 PST
As of WebKit r18639, the menu on the fed-soc.org web site is misplaced.  See Bug 12141 for details.
Comment 16 Jon 2009-08-22 11:25:56 PDT
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.
Comment 17 Gavin Barraclough 2011-06-14 16:29:37 PDT
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.
Comment 18 Jon 2011-06-14 17:11:41 PDT
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.
Comment 19 Jon 2011-06-14 17:14:32 PDT
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.
Comment 20 Gavin Barraclough 2011-06-14 17:21:45 PDT
:-(
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.
Comment 21 Jon 2011-06-14 17:48:35 PDT
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)
Comment 22 Jon 2011-06-14 18:16:20 PDT
Menu is still misplaced as well, as noted by David in #15.
Comment 23 Geoffrey Garen 2011-06-14 18:53:52 PDT
    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.
Comment 24 Gavin Barraclough 2012-09-25 13:51:21 PDT
This bug was interpreter only, the classic interpreter has now been removed from the tree.