GNOME Bugzilla – Bug 583481
Gtk::FileFilter not copied properly when passed as a local variable
Last modified: 2010-12-23 21:47:49 UTC
OS: Ubuntu 9.04 I'm trying to create some Gtk::FileFilters to be passed into a Gtk::FileChooserDialog. I have a helper function that creates the filters, but I get an null pointer when calling FileChooserDialog::get_filter() after FileChooserDialog::run(). I will attach the example application too. Here is the trace from gdb: soowei@williams:~/Development/temp/filechooserdialog$ gdb ./filechooserdialog GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) run Starting program: /home/soowei/Development/temp/filechooserdialog/filechooserdialog [Thread debugging using libthread_db enabled] [New Thread 0xb6d18720 (LWP 30883)] [New Thread 0xb659db90 (LWP 30886)] [New Thread 0xb5affb90 (LWP 30887)] [Thread 0xb5affb90 (LWP 30887) exited] (filechooserdialog:30883): glibmm-WARNING **: Glib::wrap_create_new_wrapper: Attempted to create a 2nd C++ wrapper for a C instance whose C++ wrapper has been deleted. (filechooserdialog:30883): glibmm-WARNING **: Failed to wrap object of type 'gtkmm__GtkFileFilter'. Hint: this error is commonly caused by failing to call a library init() function. Program received signal SIGSEGV, Segmentation fault.
+ Trace 215641
Thread 3067184928 (LWP 30883)
Created attachment 135132 [details] Test case To reproduce: Compile and run application. Click "Choose File". Either select a file and click Save As, or just Cancel out of the dialog. Application crashes.
Sorry for not noticing this until now. This reply is terribly late. Anyway: Of course, you should check for null pointers before dereferencing them. But yes, the point is that the Gtk::FileFilter* should not be null. The backtrace at the first warning (break g_log) isn't very interesting:
+ Trace 221705
Valgrind doesn't give any hints either. I did notice that we are refing the result of get_filter(), which is not appropriate because GtkFilter derives from GtkObject, not GObject, but fixing that does not seem to help. I guess that GTK+ is doing something strange with the underlying C pointer. It needs more investigation.
What about the following explanation? The C++ wrappers, Gtk::FileFilter, are local variables in AddFilters in the test case program. At the end of AddFilters, the Gtk::FileFilter objects are destroyed, but the wrapped GtkFileFilter objects are not, since pointers to them have been stored in the GtkFileChooserDialog object, and their ref counts have been increased accordingly. Gtk::FileFilter's destructor, or rather Gtk::Object::~Object, stores in the GObject object, a Glib::quark_cpp_wrapper_deleted_. Then the function Glib::wrap, called by Gtk::FileChooser::get_filter, refuses to create a new C++ wrapper for the GtkFileFilter object, returned by gtk_file_chooser_get_filter. I moved the code in the test case program from AddFilters to ExampleWindow::on_button_file_clicked. Then the Gtk::FileFilter objects still exist when dialog.get_filter() is called, dialog.get_filter() returns a valid pointer, and there is no segmentation fault. I've used gtkmm version 2.20.3 in Ubuntu 10.04.
Created attachment 176342 [details] Test case, modified for Gnome 3 On 2010-09-27, just a few days after I filed comment 3, Gtk::FileFilter and Gtk::FileChooser were modifed in the Gnome 3 master branch in the Git repository. Now FileFilter is accessed via Glib::RefPtr<Gtk::FileFilter>. That modification fixes this bug, as far as I can see. I've attached a modified version of the test case in comment 1. It works just fine, no segfault or other problem. But it can be compiled only with the Gnome 3 version of gtkmm.
Yes, let's just consider this fixed in gtkmm 3. Thanks.