Bug 1198891

Summary: [abrt] epiphany-runtime: webkit_web_view_get_tls_info(): epiphany killed by SIGSEGV
Product: [Fedora] Fedora Reporter: kartochka378
Component: webkitgtk4Assignee: Tomas Popela <tpopela>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: debarshir, fedora, gecko-bugs-nobody, kalevlember, mcatanzaro+wrong-account-do-not-cc, rob.townley, tpopela
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/d08fe2852036a8c9d109a894cfd2827f5dadf59f
Whiteboard: abrt_hash:6ac01379d8c1d0e9860ea334655f5a3e41f8e838
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-21 13:36:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: mountinfo
none
File: namespaces
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description kartochka378 2015-03-05 03:28:10 UTC 
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
Comment 1 kartochka378 2015-03-05 03:28:14 UTC 
Created attachment 998139 [details]
File: backtrace
Comment 2 kartochka378 2015-03-05 03:28:15 UTC 
Created attachment 998140 [details]
File: cgroup
Comment 3 kartochka378 2015-03-05 03:28:16 UTC 
Created attachment 998141 [details]
File: core_backtrace
Comment 4 kartochka378 2015-03-05 03:28:18 UTC 
Created attachment 998142 [details]
File: dso_list
Comment 5 kartochka378 2015-03-05 03:28:19 UTC 
Created attachment 998143 [details]
File: environ
Comment 6 kartochka378 2015-03-05 03:28:21 UTC 
Created attachment 998144 [details]
File: limits
Comment 7 kartochka378 2015-03-05 03:28:23 UTC 
Created attachment 998145 [details]
File: maps
Comment 8 kartochka378 2015-03-05 03:28:24 UTC 
Created attachment 998146 [details]
File: mountinfo
Comment 9 kartochka378 2015-03-05 03:28:25 UTC 
Created attachment 998147 [details]
File: namespaces
Comment 10 kartochka378 2015-03-05 03:28:26 UTC 
Created attachment 998148 [details]
File: open_fds
Comment 11 kartochka378 2015-03-05 03:28:28 UTC 
Created attachment 998149 [details]
File: proc_pid_status
Comment 12 kartochka378 2015-03-05 03:28:29 UTC 
Created attachment 998150 [details]
File: var_log_messages
Comment 13 Michael Catanzaro 2015-03-05 23:32:32 UTC 
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.
Comment 14 Michael Catanzaro 2015-03-06 01:31:47 UTC 
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.
Comment 15 Michael Catanzaro 2015-05-21 13:36:50 UTC 
Closing bugs that have been moved upstream...