| Summary: | [DumpRenderTree] Some js tests generating a large page are randomly timing out on AppleWin EWS | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Fujii Hironori <Hironori.Fujii> | ||||||
| Component: | Tools / Tests | Assignee: | Fujii Hironori <Hironori.Fujii> | ||||||
| Status: | RESOLVED DUPLICATE | ||||||||
| Severity: | Normal | CC: | ap, darin, don.olmstead, pvollan, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=223109 | ||||||||
| Attachments: |
|
||||||||
|
Description
Fujii Hironori
2021-01-17 22:36:37 PST
It's easy to reproduce this issue by invoking DumpRenderTree.exe directly. .\WebKitBuild\Debug\bin64\DumpRenderTree.exe file:///C:/webkit/LayoutTests/js/dfg-float64array.html It takes some time before DumpRenderTree.exe quits after reporitng #EOF. Created attachment 417800 [details]
Patch
Comment on attachment 417800 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=417800&action=review > Tools/ChangeLog:9 > + (runTest): Reset preferences after loading the empty page because Is there any history of this line is here? I remember that we adjusted some of these before for other reasons, maybe this very one, but am not in front of a large enough screen to check now. r177542 and r177613 changed Windows DRT to align with Mac DRT. r42056 changed Mac DRT. > * DumpRenderTree/mac/DumpRenderTree.mm: > (runTest): Added an additional call to resetWebViewToConsistentStateBeforeTesting just > before loading an empty page. This prevents extra policy delegate calls from being logged. Created attachment 417859 [details]
Patch
Making Windows DRT more like Mac one is reasonable. I've been thinking of recent changes like r267860, r256232, r244668. Looks like the latest patch breaks a couple tests on Mac. (In reply to Alexey Proskuryakov from comment #6) > Making Windows DRT more like Mac one is reasonable. I've been thinking of > recent changes like r267860, r256232, r244668. IIUC those changes, my patch is irrelevant to them. > Looks like the latest patch breaks a couple tests on Mac. Oh no. Here is the callstack of the assertion failure of accessibility/add-children-pseudo-element.html and accessibility/svg-shape-labelled.html. ASSERTION FAILED: !createIfNecessary || rootSVGObject ./accessibility/AccessibilityRenderObject.cpp(3255) : WebCore::AccessibilitySVGRoot *WebCore::AccessibilityRenderObject::remoteSVGRootElement(WebCore::AccessibilityRenderObject::CreationChoice) const 1 0x10f9baa59 WTFCrash 2 0x12b679f0b WTFCrashWithInfo(int, char const*, char const*, int) 3 0x12de67d4f WebCore::AccessibilityRenderObject::remoteSVGRootElement(WebCore::AccessibilityRenderObject::CreationChoice) const 4 0x12de5b96a WebCore::AccessibilityRenderObject::detachRemoteSVGRoot() 5 0x12de5b8ee WebCore::AccessibilityRenderObject::detachRemoteParts(WebCore::AccessibilityDetachmentType) 6 0x12dddc51f WebCore::AXCoreObject::detach(WebCore::AccessibilityDetachmentType) 7 0x12dddc0be WebCore::AXObjectCache::~AXObjectCache() 8 0x12dddc7c5 WebCore::AXObjectCache::~AXObjectCache() 9 0x12e61a39b std::__1::default_delete<WebCore::AXObjectCache>::operator()(WebCore::AXObjectCache*) const 10 0x12e61a31f std::__1::unique_ptr<WebCore::AXObjectCache, std::__1::default_delete<WebCore::AXObjectCache> >::reset(WebCore::AXObjectCache*) 11 0x12e5b8897 std::__1::unique_ptr<WebCore::AXObjectCache, std::__1::default_delete<WebCore::AXObjectCache> >::operator=(std::nullptr_t) 12 0x12e5a953c WebCore::Document::clearAXObjectCache() 13 0x12e5b6b2c WebCore::Document::destroyRenderTree() 14 0x12e5b7137 WebCore::Document::willBeRemovedFromFrame() 15 0x12f4deef0 WebCore::Frame::setView(WTF::RefPtr<WebCore::FrameView, WTF::RawPtrTraits<WebCore::FrameView>, WTF::DefaultRefDerefTraits<WebCore::FrameView> >&&) 16 0x10b24f7bd WebFrameLoaderClient::transitionToCommittedForNewPage() 17 0x12f2bb2a8 WebCore::FrameLoader::transitionToCommitted(WebCore::CachedPage*) 18 0x12f2b9f00 WebCore::FrameLoader::commitProvisionalLoad() 19 0x12f22e12c WebCore::DocumentLoader::commitIfReady() 20 0x12f22e8c2 WebCore::DocumentLoader::finishedLoading() 21 0x12f23a47d WebCore::DocumentLoader::maybeLoadEmpty() 22 0x12f23a603 WebCore::DocumentLoader::startLoadingMainResource() 23 0x12f2e7535 WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WebCore::FormState*, WebCore::NavigationPolicyDecision, WebCore::AllowNavigationToInvalidURL)::$_11::operator()() 24 0x12f2e6e59 WTF::Detail::CallableWrapper<WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WebCore::FormState*, WebCore::NavigationPolicyDecision, WebCore::AllowNavigationToInvalidURL)::$_11, void>::call() 25 0x12b688c1a WTF::Function<void ()>::operator()() const 26 0x12b6f2eaa WTF::CompletionHandler<void ()>::operator()() 27 0x12f2b70a8 WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WebCore::FormState*, WebCore::NavigationPolicyDecision, WebCore::AllowNavigationToInvalidURL) 28 0x12f2e4344 WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader*, WebCore::FrameLoadType, WTF::RefPtr<WebCore::FormState, WTF::RawPtrTraits<WebCore::FormState>, WTF::DefaultRefDerefTraits<WebCore::FormState> >&&, WebCore::AllowNavigationToInvalidURL, WTF::CompletionHandler<void ()>&&)::$_8::operator()(WebCore::ResourceRequest const&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) 29 0x12f2e420c WTF::Detail::CallableWrapper<WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader*, WebCore::FrameLoadType, WTF::RefPtr<WebCore::FormState, WTF::RawPtrTraits<WebCore::FormState>, WTF::DefaultRefDerefTraits<WebCore::FormState> >&&, WebCore::AllowNavigationToInvalidURL, WTF::CompletionHandler<void ()>&&)::$_8, void, WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision>::call(WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) 30 0x12f3196e0 WTF::Function<void (WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision)>::operator()(WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) const 31 0x12f30e1e5 WTF::CompletionHandler<void (WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision)>::operator()(WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) I just reordered loading an empty page and resetting prefs. It's weird. Anyway, I should look into it. Comment on attachment 417859 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=417859&action=review > Tools/DumpRenderTree/mac/DumpRenderTree.mm:2042 > + // Reset preferences after loading an empty page. This comment needs to say *why* we do it after loading an empty page. Just like the one on Windows does. > Tools/DumpRenderTree/win/DumpRenderTree.cpp:1343 > + // Reset preferences after loading an empty page because it takes a long time for a large page. I think the use of "it" here makes this hard to understand. I would say "because changing some settings is very slow if there is a large page already loaded." r274407 (Bug 223109) fixed this bug. *** This bug has been marked as a duplicate of bug 223109 *** |