crash in katze_net_icon_transfer_cb

[gue5t gue5t]

view->icon_uri seems to end up NULL when katze_net_icon_transfer_cb is called. This looks like a race condition due to not passing the uri to the callback as an argument.

[Cris Dywan (kalikiana)]

I haven't seen that here. Can you reproduce within a sensible timeframe? You could add some warn_if_fail to _midori_web_view_load_icon before katze_net_load_uri and inside katze_net_icon_transfer_cb. I'm thinking with warn_if_fail you can hopefully see that it only crashes when it really would otherwise, without knowing the exact condition.

[gue5t gue5t (gue5t)]

To reproduce the crash:
Start midori with an empty icon cache (via setting XDG_CACHE_HOME or otherwise) and then visit a site that has a favicon (which will then be requested).
Set the homepage to a local html file which has no favicon specified.
This next part takes some timing, but for reference it's best to try near the end of the load: go home after the request for the icon has been sent but before the icon has been received.

If instead of "going home" the user closes the tab, a set of warnings will appear (attached) instead of the browser crashing. Both of these issues are caused by the same root problem in the code: the callback doesn't ensure that view->uri will not change (possibly to NULL, but changing to another string value is also problematic), nor that the web view will still exist when the callback is executed.

[gue5t gue5t (gue5t)]

The attached shell script may be used to reproduce this bug.

[Cris Dywan (kalikiana)]

Is this still valid? I'm still not able to reproduce.

[Launchpad Janitor (janitor)]

[Expired for Midori because there has been no activity for 60 days.]