208106 2020-02-23 10:59:11 -0800 [GTK][WPE] Failing API tests under the Flatpak SDK environment 2021-09-29 06:45:24 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=205658 P2 Normal --- 208871 1 pnormand webkit-unassigned bugs-noreply dpino mcatanzaro oldest_to_newest 1622006 0 pnormand 2020-02-23 10:59:11 -0800 Unexpected failures (3) /WebKit2Gtk/TestSSL /webkit/WebKitWebView/tls-errors-policy /WebKit2Gtk/TestUIClient /webkit/WebKitWebView/javascript-dialogs /WebKit2Gtk/TestLoaderClient /webkit/WebKitWebView/is-loading Unexpected timeouts (1) /WebKit2Gtk/TestWebKitFaviconDatabase /webkit/WebKitFaviconDatabase/get-favicon I have a proposal patch for the favicon test but the others failures are very strange. Basically, if I build WebKit with the GCC toolchain provided by the SDK, I get these failures. If I use clang, no failure. Taking the tls-errors-policy example, the failures in the the GCC-built libs are very strange, because I can see that webkitWebViewLoadFail() is called during the load-failed signal emission, the captured stack-trace in webkitWebViewLoadFail(): 1 0x7f37a10819f0 /app/webkit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(+0x20f79f0) [0x7f37a10819f0] 2 0x7f3799d80fd5 /usr/lib/x86_64-linux-gnu/libffi.so.7(+0x6fd5) [0x7f3799d80fd5] 3 0x7f3799d803ea /usr/lib/x86_64-linux-gnu/libffi.so.7(+0x63ea) [0x7f3799d803ea] 4 0x7f37a45902ad g_cclosure_marshal_generic 5 0x7f37a458f7a2 g_closure_invoke 6 0x7f37a45a3086 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x29086) [0x7f37a45a3086] 7 0x7f37a45ac03e g_signal_emit_valist 8 0x7f37a45ad053 g_signal_emit 9 0x7f37a1081f67 webkitWebViewLoadFailedWithTLSErrors(_WebKitWebView*, char const*, _GError*, GTlsCertificateFlags, _GTlsCertificate*) 10 0x7f37a105613c NavigationClient::didFailProvisionalNavigationWithError(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, API::Navigation*, WebCore::ResourceError const&, API::Object*) 11 0x7f37a0f97d40 WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared(WTF::Ref<WebKit::WebProcessProxy, WTF::DumbPtrTraits<WebKit::WebProcessProxy> >&&, WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebCore::SecurityOriginData&&, unsigned long, WTF::String const&, WebCore::ResourceError const&, WebCore::WillContinueLoading, WebKit::UserData const&) 12 0x7f37a0fd3463 WebKit::WebPageProxy::didFailProvisionalLoadForFrame(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebCore::SecurityOriginData&&, unsigned long, WTF::String const&, WebCore::ResourceError const&, WebCore::WillContinueLoading, WebKit::UserData const&) 13 0x7f37a0d043ce void IPC::handleMessage<Messages::WebPageProxy::DidFailProvisionalLoadForFrame, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebCore::SecurityOriginData&&, unsigned long, WTF::String const&, WebCore::ResourceError const&, WebCore::WillContinueLoading, WebKit::UserData const&)>(IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebCore::SecurityOriginData&&, unsigned long, WTF::String const&, WebCore::ResourceError const&, WebCore::WillContinueLoading, WebKit::UserData const&)) 14 0x7f37a0cdba34 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 15 0x7f37a0eb72fa IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) 16 0x7f37a0f8f09f non-virtual thunk to WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 17 0x7f37a0eb0010 IPC::Connection::dispatchMessage(IPC::Decoder&) 18 0x7f37a0eb13e5 IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) 19 0x7f37a0eb1c7f IPC::Connection::dispatchIncomingMessages() 20 0x7f379ea96ea9 WTF::RunLoop::performWork() 21 0x7f379eaf8399 /app/webkit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18(+0x1442399) [0x7f379eaf8399] 22 0x7f37a543f58e g_main_context_dispatch 23 0x7f37a543f940 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x53940) [0x7f37a543f940] 24 0x7f37a543fc33 g_main_loop_run 25 0x55fea7537ca7 /app/webkit/WebKitBuild/Release/bin/TestWebKitAPI/WebKit2Gtk/TestSSL(+0x6ca7) [0x55fea7537ca7] 26 0x7f37a5467cae /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7bcae) [0x7f37a5467cae] 27 0x7f37a5467a54 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7ba54) [0x7f37a5467a54] 28 0x7f37a5467a54 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7ba54) [0x7f37a5467a54] 29 0x7f37a546815b g_test_run_suite 30 0x7f37a54681b5 g_test_run 31 0x55fea7536fea /app/webkit/WebKitBuild/Release/bin/TestWebKitAPI/WebKit2Gtk/TestSSL(+0x5fea) [0x55fea7536fea] 32 0x7f379a24e173 __libc_start_main 33 0x55fea753715e /app/webkit/WebKitBuild/Release/bin/TestWebKitAPI/WebKit2Gtk/TestSSL(+0x615e) [0x55fea753715e] While it's not called in the JHBuild environment, in webkitWebViewLoadFailedWithTLSErrors() the load-failed signal is emitted but the load-failed signal class closure isn't. Is that normal? If I upgrade my jhbuild to glib 2.62 (same version as in the SDK), I still can't reproduce the failure. This seems related to the toolchain, somehow... The is-loading error is due to the same (mis)behavior. The javascript-dialog failure hasn't been diagnosed yet but seems related to XvFB, if I execute the tests in my host wayland session I don't get this failure. 1628203 1 pnormand 2020-03-10 05:58:19 -0700 Hey Michael, perhaps you'd have some ideas about this issue? 1628306 2 mcatanzaro 2020-03-10 10:30:49 -0700 (In reply to Philippe Normand from comment #0) > While it's not called in the JHBuild environment, in > webkitWebViewLoadFailedWithTLSErrors() the load-failed signal is emitted but > the load-failed signal class closure isn't. Is that normal? I think I've found the problem. loadFailedCallback in LoadTrackingTest.cpp returns void, but it needs to return a gboolean. TRUE stops other handlers (including the class closure) from being invoked, FALSE continues execution of other handlers. Because the return value is missing, the result is undefined. In the past I've seen missing return values cause different behavior with different toolchains, so likely that's it. Programming is hard. :( > The is-loading error is due to the same (mis)behavior. Probably the same problem, because ViewIsLoadingTest inherits from LoadTrackingTest. 1628307 3 pnormand 2020-03-10 10:34:32 -0700 Oh wow! Thanks Michael! I'll check this further. 1628311 4 pnormand 2020-03-10 10:43:52 -0700 Yes indeed. Good catch. Thanks again. 1628321 5 pnormand 2020-03-10 10:54:24 -0700 I'll try to check the WebKitWebView/javascript-dialogs failure soon. 1798302 6 pnormand 2021-09-29 06:45:24 -0700 This was solved, I don't know when.