Carlos Garcia Campos <cgar...@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=0xF3D322D0EC4582C3Oops, 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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
