Description of problem: trying to open another tab window, crash Version-Release number of selected component: epiphany-runtime-3.15.90-3.fc23 Additional info: reporter: libreport-2.4.0 backtrace_rating: 3 cmdline: epiphany crash_function: webkit_web_view_get_tls_info executable: /usr/bin/epiphany global_pid: 4390 kernel: 4.0.0-0.rc2.git0.1.fc23.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 webkit_web_view_get_tls_info at /lib64/libwebkit2gtk-4.0.so.37 #1 load_changed_cb #6 webkitWebViewEmitLoadChanged(_WebKitWebView*, WebKitLoadEvent, bool) at /lib64/libwebkit2gtk-4.0.so.37 #7 webkitWebViewEmitDelayedLoadEvents(_WebKitWebView*) at /lib64/libwebkit2gtk-4.0.so.37 #8 webkitWebViewLoadChanged(_WebKitWebView*, WebKitLoadEvent) at /lib64/libwebkit2gtk-4.0.so.37 #9 WebKit::WebPageProxy::didStartProvisionalLoadForFrame(unsigned long, unsigned long, WTF::String const&, WTF::String const&, WebKit::UserData const&) at /lib64/libwebkit2gtk-4.0.so.37 #10 void IPC::handleMessage<Messages::WebPageProxy::DidStartProvisionalLoadForFrame, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long, unsigned long, WTF::String const&, WTF::String const&, WebKit::UserData const&)>(IPC::MessageDecoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long, unsigned long, WTF::String const&, WTF::String const&, WebKit::UserData const&)) at /lib64/libwebkit2gtk-4.0.so.37 #11 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) at /lib64/libwebkit2gtk-4.0.so.37 #12 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::MessageDecoder&) at /lib64/libwebkit2gtk-4.0.so.37 #13 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) at /lib64/libwebkit2gtk-4.0.so.37
Created attachment 998139 [details] File: backtrace
Created attachment 998140 [details] File: cgroup
Created attachment 998141 [details] File: core_backtrace
Created attachment 998142 [details] File: dso_list
Created attachment 998143 [details] File: environ
Created attachment 998144 [details] File: limits
Created attachment 998145 [details] File: maps
Created attachment 998146 [details] File: mountinfo
Created attachment 998147 [details] File: namespaces
Created attachment 998148 [details] File: open_fds
Created attachment 998149 [details] File: proc_pid_status
Created attachment 998150 [details] File: var_log_messages
I guess the WebFrameProxy's certificateInfo must be invalid (or, confusingly, the certificateInfo's certificateInfo). I don't see any other way this could happen.
So this is *interesting*. Turns out webkit_web_view_get_tls_info crashes if it's called before the internal load committed event. So on the surface, this is an easy bug to fix, we just need to return early from that function if the WebFrameProxy's certificateInfo is nullptr. But in this backtrace, the internal load event was load *started*, but Epiphany only ever uses webkit_web_view_get_tls_info in load *committed*. In this case, the previous load in the web view must have been loaded from the page cache (could be the overview goes in the page cache?), in which case the load gets committed internally before we have a main resource ready. In this case the GTK+ API layer fakes the load events it sends to the application, because it doesn't want to emit load committed before there is a main resource. So while internally WebKit's load committed event has fired, WebKitGTK+ delays the emission of the load committed event that applications hook into. But it's possible that you can start loading a new page before the WebKitGTK+ load committed event is fired, in which case the delayed WebKitGTK+ load committed event gets emitted immediately before load started. That is probably a *very* small window of time for that to occur, but if it ever happens then Epiphany will always crash, because in the WebKit internals the load has been started, and when Ephy gets the WebKitGTK+ load committed event for the previous page (emitted after the internal WebKit load started event for the new load) we call webkit_web_view_get_tls_info, which tries to get the TLS info for the new load before the internal load-committed event and crashes. Whew! I really question the wisdom of emitting load-committed after a new load has started, but I imagine it would be worse to not emit any load event... we'll have to discuss this upstream.
Closing bugs that have been moved upstream...