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 306748 - Valgrind reports leak in panel-run-dialog.c
Valgrind reports leak in panel-run-dialog.c
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-06-07 09:18 UTC by Kjartan Maraas
Modified: 2005-06-07 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (775 bytes, patch)
2005-06-07 10:17 UTC, Kjartan Maraas
accepted-commit_now Details | Review

Description Kjartan Maraas 2005-06-07 09:18:53 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)
Comment 1 Vincent Untz 2005-06-07 09:52:53 UTC
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 :-)
Comment 2 Kjartan Maraas 2005-06-07 10:17:12 UTC
Created attachment 47370 [details] [review]
proposed patch

Something like this ok?
Comment 3 Vincent Untz 2005-06-07 11:54:41 UTC
Looks ok to me. If you tested it and it works, then please commit to HEAD and
gnome-2-10.
Comment 4 Kjartan Maraas 2005-06-07 13:13:21 UTC
I tested this under valgrind now and I didn't get any new errors. Commiting to
both branches.