Bug 208106 - [GTK][WPE] Failing API tests under the Flatpak SDK environment
Summary: [GTK][WPE] Failing API tests under the Flatpak SDK environment
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 208871
  Show dependency tree / graph
 
Reported: 2020-02-23 10:59 PST by Philippe Normand
Modified: 2021-09-29 06:45 PDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Normand 2020-02-23 10:59:11 PST 
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.
Comment 1 Philippe Normand 2020-03-10 05:58:19 PDT 
Hey Michael, perhaps you'd have some ideas about this issue?
Comment 2 Michael Catanzaro 2020-03-10 10:30:49 PDT 
(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.
Comment 3 Philippe Normand 2020-03-10 10:34:32 PDT 
Oh wow! Thanks Michael! I'll check this further.
Comment 4 Philippe Normand 2020-03-10 10:43:52 PDT 
Yes indeed. Good catch. Thanks again.
Comment 5 Philippe Normand 2020-03-10 10:54:24 PDT 
I'll try to check the WebKitWebView/javascript-dialogs failure soon.
Comment 6 Philippe Normand 2021-09-29 06:45:24 PDT 
This was solved, I don't know when.