This test is a stress test of a particular algorithm inside the tree builder. It's unclear whether this test times out because the bot is slow or whether we need to make a change to the code here. Hopefully someone with access to a Gtk machine can look at what's causing the hang and let us know.
(In reply to comment #0) > This test is a stress test of a particular algorithm inside the tree builder. It's unclear whether this test times out because the bot is slow or whether we need to make a change to the code here. Hopefully someone with access to a Gtk machine can look at what's causing the hang and let us know. I've tested it in the bots and it seems the problem is slowness, because it never hangs but it takes a lot of time to finish. Is there any specific test that I could do to check if the parser is doing something wrong?
residual-style-dom.html shows the DOM that gets produced when we hit the residual style limit. That test is passing on Gtk, so I think the parser is doing the right thing. The question is if there's some reason its slower on Gtk (or if it's just the bot's hardware).
Created attachment 63564 [details] Profile of the test This is not a profile in the bot, it is a profile in my machine which is faster but I guess it could help checking if there is something not expected. If we information in the profile is ok, maybe we could increase the time we use to detect a hang a little bit, the bot machine is not very fast.
I found that chart a bit hard to read, but I think it's saying that we're spending a ton of time inside callTheAdoptionAgency, which is correct. Another option is to reduce the depth of the test case. I suspect a depth of 100 would be a sufficiently pathological test case.
(In reply to comment #4) > I found that chart a bit hard to read, but I think it's saying that we're spending a ton of time inside callTheAdoptionAgency, which is correct. Another option is to reduce the depth of the test case. I suspect a depth of 100 would be a sufficiently pathological test case. Yep, I would say basically it spends 82.82% of the time in callTheAdoptionAgency, divided this way: - WebCore::ContainerNode::appendChild 40.74% - WebCore::Element::attach 36.54% - WebCore::HTMLTreeBuilder::reparentChildren 5.21% But must of this calls end up in WebCore::Node::createRendererIfNeeded one way or another, where 71.28% of the time is spent, and gettig the style is more than half of the time creating the renderer (WebCore::CSSStyleSelector::styleForElement)
I believe that http://trac.webkit.org/changeset/64954 fixed this. If it starts timing out again, please reopen.