After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725749 - Critical warning in snapshot service
Critical warning in snapshot service
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Overview
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-05 19:32 UTC by Claudio Saavedra
Modified: 2014-03-06 08:36 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
ephy-snapshot-service: disconnect from "load-failed" signal (1.08 KB, patch)
2014-03-06 08:15 UTC, Claudio Saavedra 		committed Details | Review

Description Claudio Saavedra 2014-03-05 19:32:24 UTC 
(epiphany:15788): GLib-GIO-CRITICAL **: g_simple_async_result_set_error: assertion 'G_IS_SIMPLE_ASYNC_RESULT (simple)' failed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fffef271f6f in _g_log_abort (breakpoint=1) at gmessages.c:308
308	    G_BREAKPOINT ();
Missing separate debuginfos, use: debuginfo-install gmp-5.1.2-2.fc20.x86_64 libXres-1.0.7-2.fc20.x86_64 libxcb-1.10-1.fc21.x86_64 nettle-2.7.1-3.fc20.x86_64 trousers-0.3.11.2-1.fc20.x86_64
(gdb) back

+ Trace 233273

  • #0 _g_log_abort
    at gmessages.c line 308
  • #1 g_logv
    at gmessages.c line 1033
  • #2 g_log
    at gmessages.c line 1071
  • #3 g_return_if_fail_warning
  • #4 g_simple_async_result_set_error
    at gsimpleasyncresult.c line 719
  • #5 webview_load_failed_cb
    at ephy-snapshot-service.c line 315
  • #6 webkit_marshal_BOOLEAN__ENUM_STRING_POINTER
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #7 g_closure_invoke
    at gclosure.c line 768
  • #8 signal_emit_unlocked_R
    at gsignal.c line 3551
  • #9 g_signal_emit_valist
    at gsignal.c line 3317
  • #10 g_signal_emit
    at gsignal.c line 3363
  • #11 webkitWebViewLoadFailed(_WebKitWebView*, WebKitLoadEvent, char const*, _GError*)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #12 didFailProvisionalLoadWithErrorForFrame(OpaqueWKPage const*, OpaqueWKFrame const*, OpaqueWKError const*, void const*, void const*)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #13 WKPageSetPageLoaderClient::LoaderClient::didFailProvisionalLoadWithErrorForFrame(WebKit::WebPageProxy*, WebKit::WebFrameProxy*, WebCore::ResourceError const&, API::Object*)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #14 WebKit::WebPageProxy::didFailProvisionalLoadForFrame(unsigned long, WebCore::ResourceError const&, IPC::MessageDecoder&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #15 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection*, IPC::MessageDecoder&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #16 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection*, IPC::MessageDecoder&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #17 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection*, IPC::MessageDecoder&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #18 IPC::Connection::dispatchMessage(std::unique_ptr<IPC::MessageDecoder, std::default_delete<IPC::MessageDecoder> >)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #19 IPC::Connection::dispatchOneMessage()
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #20 WTF::RunLoop::performWork()
    from /opt/gnome-3.0/lib64/libjavascriptcoregtk-3.0.so.0
  • #21 WTF::RunLoop::queueWork(WTF::RunLoop*)
    from /opt/gnome-3.0/lib64/libjavascriptcoregtk-3.0.so.0
  • #22 g_idle_dispatch
  • #23 g_main_dispatch
    at gmain.c line 3064
  • #24 g_main_context_dispatch
    at gmain.c line 3663
  • #25 g_main_context_iterate
    at gmain.c line 3734
  • #26 g_main_context_iteration
    at gmain.c line 3795
  • #27 g_application_run
    at gapplication.c line 2114
  • #28 main
    at ephy-main.c line 488 






Comment 1


Claudio Saavedra





          2014-03-06 08:10:47 UTC
        



I think we should be disconnecting from the "load-failed" signal in the snapshot service, and we currently don't. Carlos, what do you think?






Comment 2


Claudio Saavedra





          2014-03-06 08:15:14 UTC
        



Created attachment 271072 [details] [review]
ephy-snapshot-service: disconnect from "load-failed" signal

Otherwise we have a dangling handler with webviews that are
unrelated to the async result at hand.






Comment 3


Claudio Saavedra





          2014-03-06 08:25:12 UTC
        



Attachment 271072 [details] pushed as fb84c77 - ephy-snapshot-service: disconnect from "load-failed" signal






Comment 4


Carlos Garcia Campos





          2014-03-06 08:26:36 UTC
        



I think we should not ref the web view in any case, and use a weak pointer instead, checking if it's null before trying to use it and cancelling the async operation when it becomes null.






Comment 5


Claudio Saavedra





          2014-03-06 08:36:13 UTC
        



Yes, that probably makes sense.