GNOME Bugzilla – Bug 554618
GtkFileChooserDialog leaks memory
Last modified: 2014-02-21 19:52:03 UTC
Please describe the problem: Upon creation of a GtkFileChooserDialog, the memory usage of my program goes from 2.7mb to 5.5mb which is fine, but upon the destruction of the dialog, the memory isn't freed and another 100kb is used. Upon successive creations and destructions of dialogs, 100kb to 300kb of memory are leaked. After awhile doing this (creating and destroying), this is printed to the shell: /* begin message from shell */ (main:7648): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (main:7648): GLib-GObject-CRITICAL **: g_signal_handlers_block_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (main:7648): Gtk-CRITICAL **: gtk_combo_box_set_active: assertion `GTK_IS_COMBO_BOX (combo_box)' failed (main:7648): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (main:7648): GLib-GObject-CRITICAL **: g_signal_handlers_unblock_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (main:7648): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkFileSystemGio' /* end message from shell */ The problem is worse on windows, where it will get to about 12mb of memory and then crash. Steps to reproduce: 1. Create a GtkFileChooserDialog 2. Destroy the GtkFileChooserDialog Actual results: The memory used by the dialog isn't freed Expected results: The memory used by the dialog is freed Does this happen every time? Yes Other information:
Created attachment 119740 [details] Small program that demonstrates the problem
I'd like to add that this affects GtkFileChooserWidget too, so I'm guessing that it's not a problem with the GtkFileChooserDialog
Updated info about version numbers. The bug still exists using Ubuntu 8.10 beta with GNOME 2.24.0 and GTK+ 2.14.3.
This bug is present on Windows, GTK+ version 2.16.6, when using gtk_file_chooser_button. Every time you click on the button and then close the dialog, it uses more memory and opens more handles. Code: #include <gtk/gtk.h> int main (int argc, char **argv) { GtkWidget *window, *chooser1; gtk_init(&argc, &argv); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); chooser1 = gtk_file_chooser_button_new ("Open", GTK_FILE_CHOOSER_ACTION_OPEN); gtk_container_add (GTK_CONTAINER (window), chooser1); gtk_widget_show_all (window); gtk_main(); return 0; }
The problem in comment #4 might very well be a different bug than that originally reported, though. Please file a separate bug specifically for the apparent leak on Windows.
Bug commented in #4 was reported here: https://bugzilla.gnome.org/show_bug.cgi?id=594961
The memory leak does not seem to be as bad as the initial report any more but it does still exist.
*** Bug 594961 has been marked as a duplicate of this bug. ***
Created attachment 269945 [details] [review] Unregister the popover before destroying it Fixes a leak of the registered_windows list in GtkWidget.
Created attachment 269946 [details] [review] Don't leak the queried file info
The other part of this is bug 695965.
Attachment 269945 [details] pushed as c287845 - Unregister the popover before destroying it Attachment 269946 [details] pushed as e709c96 - Don't leak the queried file info