GNOME Bugzilla – Bug 768250
Crash when restoring session
Last modified: 2016-10-17 12:22:44 UTC
Last evening I had to close ephy because of a tab being blocked (I think down to dri3/libva being funny here, not the only issue I have around it). Thing is, when I restarted the ephy, I was greeted each time with this backtrace:
+ Trace 236401
First thing worth pointing out is the invalid "http:/" uri, I can't assure that this invalid url belongs to the tab that caused the blocking or not, nor I can assure that the tab was previously like that when the session was saved. One thing I can assure is, I didn't write that, nor reached there through clicking. I sometimes see blank tabs after restoring a session (unclean exits might be related?), I wonder if this is a related issue. Aside of these issues, ephy should startup :). Attaching a small patch to bail out if the SoupURI could not be constructed. PS. in case it was not clear, I've got restore-session-policy=always in settings PPS. I'm reporting this to 3.20, the issue might apply to master, but I've been admittedly lazy at compiling WebKit...
Created attachment 330664 [details] [review] embed: Bail out early on invalid uri Fixes crash a bit later when accessing soup_uri memory. If there is no uri, there's not much to do here...
Review of attachment 330664 [details] [review]: I wish we knew where the http:/ URI was coming from. Oh well, thanks for your patch. ::: embed/ephy-web-view.c @@ +1425,3 @@ soup_uri = soup_uri_new (uri); + if (!soup_uri) In this case we should probably still update the security level to EPHY_SECURITY_LEVEL_LOCAL_PAGE (no security indicator), just in case this somehow happens when the security level is something else, so I would instead add the !soup_uri check to the first condition down below, and then just null-check it before freeing it.
Created attachment 330669 [details] [review] embed: Check for NULL SoupURI when trying to load invalid url Fixes crashes when accessing soup_uri memory. If there is no valid uri, just set the "local page" security level.
(In reply to Michael Catanzaro from comment #2) > Review of attachment 330664 [details] [review] [review]: > > I wish we knew where the http:/ URI was coming from. Oh well, thanks for > your patch. I agree, and would like to track this down (also for the lost blank tabs), first I'd like to find out if it clean/unclean ephy shutdowns influenced. Sadly, session durability/stability is not one of my dev machine features :)
Review of attachment 330669 [details] [review]: OK
Also for gnome-3-20
Cheers! pushing to both branches Attachment 330669 [details] pushed as 8d9adfe - embed: Check for NULL SoupURI when trying to load invalid url
(In reply to Carlos Garnacho from comment #4) > I agree, and would like to track this down (also for the lost blank tabs), > first I'd like to find out if it clean/unclean ephy shutdowns influenced. > Sadly, session durability/stability is not one of my dev machine features :) OK, I have a reproducer. It's not a very good reproducer, though. Create a web extension that calls some function that cannot be resolved at link time. In my case, I built Epiphany against a libhttpseverywhere API that got removed. Now the web process cannot start. When you close Epiphany and reopen, http:/ gets saved for each tab in the session file. This shouldn't happen.
I never had a good reproducer myself either :(. AFAICS it usually happens on old opened tabs that go through several close/reboot/(session) kill/OOM cycles (my tab hoarding doesn't help :). Now, I'm pretty sure that nowadays I see more often just "Blank page" tabs that were supposedly restored pages than "http:/" ones.
The following fix has been pushed: e212e2f session: Add a safety check
Created attachment 337842 [details] [review] session: Add a safety check Never replace a good session file with one that's known to be broken.