[webkit-gtk] Memory leaks creating and removing webviews

[Josh Rickmar]

Carlos Garcia Campos <cgarcia at igalia.com> wrote:

> El mié, 12-06-2013 a las 14:49 -0400, Josh Rickmar escribió:
> > This issue may have already been beaten to death, but I am seeing
> > pretty bad memory leaks when creating, showing and, and then deleting
> > WebKitWebView widgets.  I've written and attached a very small test
> > browser that will open tabs to Google's homepage, with a button on
> > each tab to remove the tab and free everything in that notebook's
> > page's container.  From what I can observe with top, I lose roughly 3
> > MB per each tab open and close.
> > 
> > From what I can tell based on the GTK and WebKitGtk docs, I am
> > managing all the memory correctly even with this small test browser.
> > If I am doing anything incorrect that may help with the leaks, please
> > let me know.  Otherwise, what parts of the Webkit or WebKitGtk code
> > should be examined first for leaks?
> > 
>
> > 
> > 
> > void
> > new_tab(GtkNotebook *nb)
> > {
> >         GtkWidget       *b;
> >         GtkWidget       *close_btn;
> >         GtkWidget       *wv;
> >         close_btn_args  *args;
> > 
> >         wv = webkit_web_view_new();
> >         webkit_web_view_load_uri(WEBKIT_WEB_VIEW(wv),
> >             "https://www.google.com/");
> >         g_object_ref_sink(G_OBJECT(wv));
>
> This is wrong, and it's leaking the view. GtkWidgets are created with a
> floating reference that is consumed by the container widget when it's
> added to a container. In this case here you are converting the floating
> reference into a hard reference, the ref counter is 1. When the view is
> added to the GtkNotebook, ref_sink is called again, but when ref_sink is
> called on a GObject with a hard reference, it's reference counter is
> increased, so it will be 2. When the tab is destroyed the notebook page
> releases its reference, but the web view still has 1 and it's not
> destroyed.
>
> >         close_btn = gtk_button_new();
> >         gtk_button_set_image(GTK_BUTTON(close_btn),
> > gtk_image_new_from_stock
> >             (GTK_STOCK_CLOSE, GTK_ICON_SIZE_SMALL_TOOLBAR));
> >         args = g_malloc0(sizeof *args);
> >         args->nb = nb;
> >         args->child = wv;
> >         g_signal_connect(close_btn, "clicked",
> > G_CALLBACK(close_btn_cb), args);
> > 
> >         b = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 1);
> >         gtk_box_pack_start(GTK_BOX(b), close_btn, FALSE, FALSE, 0);
> >         gtk_box_pack_start(GTK_BOX(b), gtk_label_new("Tab Label"),
> > FALSE,
> >             FALSE, 0);
> >         gtk_widget_show_all(b);
> > 
> >         gtk_notebook_append_page(nb, wv, b);
> >         gtk_widget_show_all(GTK_WIDGET(nb));
> > }
> > 
> > 
>
> -- 
> Carlos Garcia Campos
> http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

Oops, that's a good catch.  Indeed that will leak.  I had revised this
test a few times to see if sinking the floating reference, and then
manually unreferencing it in close_btn_cb would make any difference,
but it didn't.  This was just a leftover of that test.  Remove that
line and see for yourself, it will still leak ~3MB.

-- 
Josh Rickmar
http://jrick.devio.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2527 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20130613/8abb8b35/attachment-0001.bin>