GNOME Bugzilla – Bug 422955
The application crashes with SIGSEGV in ComboBoxText destructor
Last modified: 2007-05-02 22:24:20 UTC
Steps to reproduce: I have written the small program that demonstrates this crash. I'll attach the source to this bug. 1. Compile the program: g++ `pkg-config --cflags --libs gtkmm-2.4` -ggdb a.cpp 2. Run it 3. On the first page of Gtk::Notebook (which is currently opened) click the ComboBoxText, and select the sole item 4. Switch to the second page. The ComboBoxText on it will have focus. 5. Close the window. The application will crash with the following message: (a.out:9835): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed Segmentation fault (core dumped) Stack trace: If application is run in regular manner, the stack trace doesn't show anything useful (it appears that at the moment of segfault the stack frame information is inconsistent):
+ Trace 122323
Other information: I am using Gentoo with gtk-2.10.9 and gtkmm-2.8.3. The same bug was observed on Suse 10.2 with gtk-2.10.6 and gtkmm-2.10.2. I have also observed that if you move focus on the second page away from ComboBoxText, the crash won't happen.
Created attachment 85312 [details] The program demonstating the crash
I can't reproduce this, and valgrind doesn't show any problems when doing this either. Do you have similar problems with the gtkmm examples? I suspect a gentoo-related problem.
(In reply to comment #2) > I can't reproduce this, and valgrind doesn't show any problems when doing this > either. When application crashes, valgrind doesn't show any errors, too (except for the segfault itself, of course). I suppose that it doesn't relate to incorrect memory access, but it is concerned with reference counting. Probably it is related to focus handling. I have found that there is two requirements for crash: 1. during the lifetime of window, first combobox gets focus at some moment 2. when the window is being destroyed, the second combobox (on the second page) has focus > Do you have similar problems with the gtkmm examples? I suspect a > gentoo-related problem. I can't find suitable example (two comboboxes on different pages of Gtk::Notebook). Other gtkmm programs (inkscape for example) work well - the problem appears only under very special conditions, such as described above. I don't think that this bug is gentoo-related. As I have noticed above, the same behavior (crash) is observed on SuSe 10.2 (x86). Maybe your architecture is different from mine? I'm using x86 (p3m and p4-based celeron). If you are not, please, try to test it on x86. I can post the core dumps if required.
OK. Please post a gdb backtrace, with debugging symbols. Maybe I am not reproducing the steps correctly. For instance, "On the first page of Gtk::Notebook (which is currently opened) click the ComboBoxText, and select the sole item" is odd, because the sole item is already selected.
(In reply to comment #4) > OK. Please post a gdb backtrace, with debugging symbols. OK, I'll do it during the time. I need to recompile gtkmm with debugging symbols enabled to do this. > Maybe I am not reproducing the steps correctly. For instance, "On the first > page of Gtk::Notebook (which is currently opened) click the ComboBoxText, and > select the sole item" is odd, because the sole item is already selected. Yes, apparently, you didn't understand me correctly. It isn't important what item is selected in combobox; but it is important that combobox receives input focus. To reproduce the crash, you need to move focus to the first combobox (no matter how - by keyboard or by mouse), then switch to the second page, move focus to the second combobox (if it isn't there already), then close the window. At the moment of the destruction of the window, the second combobox should have focus.
Yes, I can now reproduce it on both Ubuntu Edgy and Ubuntu Feisty. I have to click twice on each combo box and then close the window. I get: murrayc@murrayc-desktop:~$ ./a.out (a.out:10439): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed Segmentation fault (core dumped) valgrind shows me: (a.out:10496): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed ==10496== ==10496== Invalid read of size 4 ==10496== at 0x490F00A: g_type_class_meta_marshal (gclosure.c:565) ==10496== by 0x491081A: g_closure_invoke (gclosure.c:490) ==10496== by 0x4921789: signal_emit_unlocked_R (gsignal.c:2370) ==10496== by 0x4922816: g_signal_emit_valist (gsignal.c:2199) ==10496== by 0x49229D8: g_signal_emit (gsignal.c:2243) ==10496== by 0x44686B3: gtk_container_set_focus_child (gtkcontainer.c:1356) ==10496== by 0x461E274: gtk_widget_unparent (gtkwidget.c:2091) ==10496== by 0x445E9AE: gtk_combo_box_menu_destroy (gtkcombobox.c:2680) ==10496== by 0x4464B2D: gtk_combo_box_finalize (gtkcombobox.c:5011) ==10496== by 0x4912B6B: g_object_unref (gobject.c:1788) ==10496== by 0x4912EB7: g_object_run_dispose (gobject.c:574) ==10496== by 0x451E09D: gtk_object_destroy (gtkobject.c:403) ==10496== by 0x41F1A48: Gtk::Object::_destroy_c_instance() (object.cc:166) ==10496== by 0x41F1B6E: Gtk::Object::destroy_() (object.cc:264) ==10496== by 0x41B5120: Gtk::ComboBox::~ComboBox() (combobox.cc:230) ==10496== by 0x804D8D1: Gtk::ComboBoxText::~ComboBoxText() (in /home/murrayc/a.out) ==10496== by 0x804DEDE: page::~page() (in /home/murrayc/a.out) ==10496== by 0x804E532: nb::~nb() (in /home/murrayc/a.out) ==10496== by 0x804D795: main (in /home/murrayc/a.out) ==10496== Address 0x0 is not stack'd, malloc'd or (recently) free'd We really need a a C test case to confirm that this is not a gtkmm bug.
(In reply to comment #6) > We really need a a C test case to confirm that this is not a gtkmm bug. I also suspect that it may be a GTK+ (not gtkmm) bug. But, unfortunately, I don't know GTK+ well enough to write an equivalent program in pure GTK+.
I was unable to create a GTK+ testcase because the problem is that in gtkmm, windows do not call the base class implementation in the dispose vfunc (which seems to be intentional) and therefore the order and time of the widget hierarchy destruction differs from an equivalent simple plain GTK+ version. The problem actually is that when the combobox is destroyed, it destroys its popup widget which in turn causes the focus of the combobox to change which fails because the combobox itself is currently being destroyed. I created a GTK+ bug report (#430746) with a patch that fixes the problem by destroying that popup widget in _dispose.
This testcase does not crash any more with the patch in #430746 being committed.