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 673795 - async bookmarks icon handling cannot work in gtk tree model get value for a cell area
async bookmarks icon handling cannot work in gtk tree model get value for a c...
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Bookmarks
git master
Other Linux
: Normal critical
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 681839 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-04-09 20:35 UTC by Alban Browaeys
Modified: 2012-09-03 10:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
bookmarks: remove async call in handler for gtk tree model get value (2.58 KB, patch)
2012-04-09 20:35 UTC, Alban Browaeys
rejected Details | Review
Added ephy_node_view_get_iter_for_node() (2.13 KB, patch)
2012-08-24 10:21 UTC, Sergio Villar
committed Details | Review
EphyBookmarksEditor: force a repaint of the row when we get a favicon (3.64 KB, patch)
2012-08-24 10:24 UTC, Sergio Villar
committed Details | Review

Description Alban Browaeys 2012-04-09 20:35:22 UTC
Created attachment 211671 [details] [review]
bookmarks: remove async call in handler for gtk tree model get value

gtk cell area apply cell attributes calls gtk tree model get value then unset the gvalue.
Passing the gvalue to an async callback in the gtk tree model get value ephy handle
calls for trouble and segfault here . Ie the gvalue is unset before use.

This probably requires waiting for the async calls to returns. Here
I remove the async call completely.

Remove async icon_loaded_cb call in handler ephy_tree_model_node_get_value
for gtk tree model get value as gtk cell area apply_cell_attributes calls
synchroneously gtk_tree_model_get_value with a gvalue passed.
This gvalue is passed to ephy_tree_model_node_get_value then provide_favicon
which in the async webkit_favicon_database_get_favicon_pixbuf with the icon_loaded_cb
handler.
The latter takes the former gvalue as user_data. The async calls returns immediatly then
we return to apply_cell_attributes which gets the gvalue and unset it. Then the gvalue is reused
for other data type.
Though webkit_favicon_database_get_favicon_pixbuf then executes the icon_loaded_cb callback passing
it the then unset and reused gvalue as user_data. This leads to G_VALUE_HOLDS_OBJECT critical error
from glib then segfault from ephy bookmarks icon_loaded_cb code.
Comment 1 Carlos Garcia Campos 2012-08-14 13:38:34 UTC
*** Bug 681839 has been marked as a duplicate of this bug. ***
Comment 2 Carlos Garcia Campos 2012-08-14 13:42:29 UTC
Review of attachment 211671 [details] [review]:

The patch fixes the critical warnings, and a potencial crash because of the stack allocated memory usage, but of course it doesn't fix the real issue. We need a way to update the model with the icon when it's loaded. In any case I would apply this patch for now, because current code is broken.
Comment 3 Xan Lopez 2012-08-14 14:43:56 UTC
Sergio wrote this originally, he should have a look at it.
Comment 4 Sergio Villar 2012-08-14 14:55:28 UTC
So, I am not an expert on EphyNode but I guess the right fix in this case is to get a GtkTreeRowReference in provide_favicon() if webkit_favicon_database_try_get_favicon_pixbuf() does not return anything. That row reference is passed as user_data to the asynchronous call.

Once the callback is invoked, we just need to force a repaint using gtk_tree_model_row_changed(). Does it make sense? Is it possible to get that row reference from an EphyNode?
Comment 5 Xan Lopez 2012-08-17 14:50:13 UTC
(In reply to comment #4)
> So, I am not an expert on EphyNode but I guess the right fix in this case is to
> get a GtkTreeRowReference in provide_favicon() if
> webkit_favicon_database_try_get_favicon_pixbuf() does not return anything. That
> row reference is passed as user_data to the asynchronous call.
> 
> Once the callback is invoked, we just need to force a repaint using
> gtk_tree_model_row_changed(). Does it make sense? Is it possible to get that
> row reference from an EphyNode?

As far as I remember we use an EphyNodeView here, which *is* a GtkTreeView, so it should be possible to get a GtkTreeRowReference. You can also translate back and forth from EphyNodes to GtkTreeIters with the methods in EphyTreeModelNode, in case you need to do that.
Comment 6 Claudio Saavedra 2012-08-17 15:16:06 UTC
So I faced a crasher after launching ephy with the bookmarks window open. The stacktrace is this:

  • #0 type_check_is_value_type_U
    at gtype.c line 4104
  • #1 g_type_check_value_holds
    at gtype.c line 4145
  • #2 g_value_take_object
    at gobject.c line 3453
  • #3 icon_loaded_cb
    at ephy-bookmarks-editor.c line 1483
  • #4 g_simple_async_result_complete
    at gsimpleasyncresult.c line 775
  • #5 IconDatabaseClientGtk::didImportIconDataForPageURL(WTF::String const&)
    from /opt/gnome-3.0/lib64/libwebkitgtk-3.0.so.0
  • #6 WebCore::ImportedIconDataForPageURLWorkItem::performWork()
    from /opt/gnome-3.0/lib64/libwebkitgtk-3.0.so.0
  • #7 WebCore::performWorkItem(void*)
    from /opt/gnome-3.0/lib64/libwebkitgtk-3.0.so.0
  • #8 WTF::dispatchFunctionsFromMainThread()
    from /opt/gnome-3.0/lib64/libjavascriptcoregtk-3.0.so.0
  • #9 WTF::timeoutFired(void*)
    from /opt/gnome-3.0/lib64/libjavascriptcoregtk-3.0.so.0
  • #10 g_timeout_dispatch
  • #11 g_main_dispatch
    at gmain.c line 2707
  • #12 g_main_context_dispatch
    at gmain.c line 3211
  • #13 g_main_context_iterate
    at gmain.c line 3282
  • #14 g_main_context_iteration
    at gmain.c line 3343
  • #15 g_application_run
    at gapplication.c line 1607
  • #16 main
    at ephy-main.c line 493


In order to reproduce this I'd say it's enough to open the bookmarks window and close it (or just break it) and then launch it again. EphySession will try to open the bookmarks window and boom!
Comment 7 Sergio Villar 2012-08-17 19:35:40 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Once the callback is invoked, we just need to force a repaint using
> > gtk_tree_model_row_changed(). Does it make sense? Is it possible to get that
> > row reference from an EphyNode?
> 
> As far as I remember we use an EphyNodeView here, which *is* a GtkTreeView, so
> it should be possible to get a GtkTreeRowReference. You can also translate back
> and forth from EphyNodes to GtkTreeIters with the methods in EphyTreeModelNode,
> in case you need to do that.

You know that code better than me, but gtk_tree_view_get_model(ephy-node-view)
will return a GtkTreeModel which is not an EphyTreeModelNode (because the
EphyNodeView wraps it with a filter and a sort model). So if I am not wrong, I
cannot do anything with the EphyNode if I do not have access to the
EphyTreeModelNode.
Comment 8 Xan Lopez 2012-08-17 20:02:28 UTC
(In reply to comment #7)
> You know that code better than me, but gtk_tree_view_get_model(ephy-node-view)
> will return a GtkTreeModel which is not an EphyTreeModelNode (because the
> EphyNodeView wraps it with a filter and a sort model). So if I am not wrong, I
> cannot do anything with the EphyNode if I do not have access to the
> EphyTreeModelNode.

Both GtkTreeModelSort and GtkTreeModelFilter have methods to access the underlying model, no?
Comment 9 Sergio Villar 2012-08-20 08:08:23 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > You know that code better than me, but gtk_tree_view_get_model(ephy-node-view)
> > will return a GtkTreeModel which is not an EphyTreeModelNode (because the
> > EphyNodeView wraps it with a filter and a sort model). So if I am not wrong, I
> > cannot do anything with the EphyNode if I do not have access to the
> > EphyTreeModelNode.
> 
> Both GtkTreeModelSort and GtkTreeModelFilter have methods to access the
> underlying model, no?

Sure, I was not sure that you wanted to break the encapsulation as the tree models structure is an internal detail.
Comment 10 Sergio Villar 2012-08-24 10:21:25 UTC
Created attachment 222297 [details] [review]
Added ephy_node_view_get_iter_for_node()

We need this function to create a proper GtkTreeRowReference from a EphyNode.
Comment 11 Sergio Villar 2012-08-24 10:24:47 UTC
Created attachment 222298 [details] [review]
EphyBookmarksEditor: force a repaint of the row when we get a favicon

Instead of trying to set the favicon in an already released GValue we just force a repaint of the row and let provide_favicon set the GValue properly.
Comment 12 Carlos Garcia Campos 2012-08-24 13:25:26 UTC
Review of attachment 222298 [details] [review]:

LGTM

::: src/bookmarks/ephy-bookmarks-editor.c
@@ +1486,3 @@
+	    /* Force repaint. */
+	    if (gtk_tree_model_get_iter (model, &iter, path))
+		    gtk_tree_model_row_changed (model, path, &iter);

So, this will call provide_favicon again?
Comment 13 Sergio Villar 2012-08-24 13:58:30 UTC
(In reply to comment #12)
> Review of attachment 222298 [details] [review]:
> 
> LGTM
> 
> ::: src/bookmarks/ephy-bookmarks-editor.c
> @@ +1486,3 @@
> +        /* Force repaint. */
> +        if (gtk_tree_model_get_iter (model, &iter, path))
> +            gtk_tree_model_row_changed (model, path, &iter);
> 
> So, this will call provide_favicon again?

Yes because that's the callback registered to provide the icon, I mean, I have not deeply followed the code, but as EphyNodeView is a GtkTreeView I assumed that it should work the same way.
Comment 14 Xan Lopez 2012-08-29 17:46:06 UTC
Review of attachment 222297 [details] [review]:

OK.
Comment 15 Xan Lopez 2012-08-29 17:46:20 UTC
Review of attachment 222298 [details] [review]:

OK.

::: src/bookmarks/ephy-bookmarks-editor.c
@@ +1492,3 @@
+
+    gtk_tree_row_reference_free (reference);
+    g_clear_object (&favicon);

Using clear_object seems over the top here, since it's a local variable.
Comment 16 Xan Lopez 2012-09-02 00:00:13 UTC
Comment on attachment 211671 [details] [review]
bookmarks: remove async call in handler for gtk tree model get value

This patch is obsolete now, removing from review queue.
Comment 17 Sergio Villar 2012-09-03 10:26:56 UTC
All changes have landed.