GNOME Bugzilla – Bug 306748
Valgrind reports leak in panel-run-dialog.c
Last modified: 2005-06-07 13:13:21 UTC
This backtrace indicates a leak, but the code says gtk+ is supposed to unref the pixbuf for us: if (icon_path) pixbuf = panel_load_icon (gtk_icon_theme_get_default (), icon_path, ICON_SIZE, NULL); if (pixbuf) { dialog->icon_path = g_strdup (icon_path); /* Don't bother scaling the image if it's too small. * Scaled looks worse than a smaller image. */ gtk_image_set_from_pixbuf (GTK_IMAGE (dialog->pixmap), pixbuf); gtk_window_set_icon (GTK_WINDOW (dialog->run_dialog), pixbuf); /* Don't unref pixbuf here, GTK will do it for us. */ gtk_drag_source_set_icon_pixbuf (dialog->run_dialog, pixbuf); } else { gtk_image_set_from_icon_name (GTK_IMAGE (dialog->pixmap), PANEL_RUN_ICON, GTK_ICON_SIZE_DIALOG); gtk_window_set_icon_name (GTK_WINDOW (dialog->run_dialog), PANEL_RUN_ICON); /* FIXME: waiting for bug #116577 gtk_drag_source_set_icon_name (dialog->run_dialog, PANEL_RUN_ICON); */ } } ==670== 9268 (52 direct, 9216 indirect) bytes in 1 blocks are definitely lost in loss record 13765 of 15025 ==670== at 0x1B9056BC: calloc (vg_replace_malloc.c:350) ==670== by 0x1C668623: g_malloc0 (gmem.c:154) ==670== by 0x1C5D368C: g_type_create_instance (gtype.c:1576) ==670== by 0x1C5BA77B: g_object_constructor (gobject.c:1045) ==670== by 0x1C5BADD7: g_object_newv (gobject.c:942) ==670== by 0x1C5BB93E: g_object_new_valist (gobject.c:1026) ==670== by 0x1C5BBA5D: g_object_new (gobject.c:823) ==670== by 0x1C4DBE1B: gdk_pixbuf_new_from_data (gdk-pixbuf-data.c:65) ==670== by 0x1C4DA572: gdk_pixbuf_new (gdk-pixbuf.c:304) ==670== by 0x1D054F4F: png_info_callback (io-png.c:609) ==670== by 0x1D093C4B: png_push_have_info (in /usr/lib/libpng12.so.0.1.2.8) ==670== by 0x1D095404: png_push_read_chunk (in /usr/lib/libpng12.so.0.1.2.8) ==670== by 0x1D095FBD: png_process_some_data (in /usr/lib/libpng12.so.0.1.2.8) ==670== by 0x1D096025: png_process_data (in /usr/lib/libpng12.so.0.1.2.8) ==670== by 0x1D054D66: gdk_pixbuf__png_image_load_increment (io-png.c:512) ==670== by 0x1C4DEBF7: gdk_pixbuf_loader_load_module (gdk-pixbuf-loader.c:421) ==670== by 0x1C4DEEC9: gdk_pixbuf_loader_write (gdk-pixbuf-loader.c:444) ==670== by 0x1C4DD2DE: gdk_pixbuf_new_from_file_at_scale (gdk-pixbuf-io.c:1086) ==670== by 0x1C4DD49C: gdk_pixbuf_new_from_file_at_size (gdk-pixbuf-io.c:986) ==670== by 0x8071DC4: panel_load_icon (panel-util.c:606) ==670== by 0x80748DE: panel_run_dialog_set_icon (panel-run-dialog.c:178) ==670== by 0x80758B4: program_list_selection_changed (panel-run-dialog.c:937) ==670== by 0x1C5C0EFC: g_cclosure_marshal_VOID__VOID (gmarshal.c:77) ==670== by 0x1C5B60EB: g_closure_invoke (gclosure.c:437) ==670== by 0x1C5C4272: signal_emit_unlocked_R (gsignal.c:2488) ==670== by 0x1C5C5636: g_signal_emit_valist (gsignal.c:2247) ==670== by 0x1C5C59D6: g_signal_emit (gsignal.c:2291) ==670== by 0x1C2575DC: _gtk_tree_selection_internal_select_node (gtktreeselection.c:1511) ==670== by 0x1C267A78: gtk_tree_view_real_set_cursor (gtktreeview.c:11097) ==670== by 0x1C26F925: gtk_tree_view_button_press (gtktreeview.c:2391)
From GTK+ code: /** * gtk_drag_source_set_icon_pixbuf: * @widget: a #GtkWidget * @pixbuf: the #GdkPixbuf for the drag icon * * Sets the icon that will be used for drags from a particular widget * from a #GdkPixbuf. GTK+ retains a reference for @pixbuf and will * release it when it is no longer needed. **/ void gtk_drag_source_set_icon_pixbuf (GtkWidget *widget, GdkPixbuf *pixbuf) { GtkDragSourceSite *site; g_return_if_fail (GTK_IS_WIDGET (widget)); g_return_if_fail (GDK_IS_PIXBUF (pixbuf)); site = g_object_get_data (G_OBJECT (widget), "gtk-site-data"); g_return_if_fail (site != NULL); g_object_ref (pixbuf); gtk_drag_source_unset_icon (site); site->icon_type = GTK_IMAGE_PIXBUF; site->icon_data.pixbuf.pixbuf = pixbuf; } So it seems the comment is wrong :-) Patches welcome :-)
Created attachment 47370 [details] [review] proposed patch Something like this ok?
Looks ok to me. If you tested it and it works, then please commit to HEAD and gnome-2-10.
I tested this under valgrind now and I didn't get any new errors. Commiting to both branches.