GNOME Bugzilla – Bug 350734
segfault in RadioAction constructor
Last modified: 2007-04-18 16:34:10 UTC
When trying to inherit from RadioAction, the constructor causes a segfault. This occurs at least in 2.6 and later. Example program: #include <glibmm/refptr.h> #include <gtkmm/main.h> #include <gtkmm/radioaction.h> #include <gtkmm/stock.h> namespace { class Radio_action : public Gtk::RadioAction { public: Radio_action (Group& group) : Gtk::RadioAction (group, "test", Gtk::StockID (), "", "") { } static Glib::RefPtr <Radio_action> create (Group& group) { return Glib::RefPtr <Radio_action> (new Radio_action (group)); } }; } int main (int argc, char** argv) { Gtk::Main main (argc, argv); Radio_action::Group test_group; #if 1 // This segfaults. Radio_action::create (test_group); #else Gtk::RadioAction::create (test_group, "test"); #endif return 0; } stack trace: (gdb) run Starting program: /home/doug/testprg/a.out [Thread debugging using libthread_db enabled] [New Thread 46912496377392 (LWP 16809)] Program received signal SIGSEGV, Segmentation fault.
+ Trace 70187
Thread 46912496377392 (LWP 16809)
Created attachment 70644 [details] Test case that doesn't segfault Adding Glib::ObjectBase(0) to the static initialization of the constructor prevents the segfault.
Interesting. Clearly we don't want to have to actually do that manually in our derived classes though. I don't have a lot of time in the next few days, but i'll try to dig into this a bit more at some point unless somebody comes up with something better before I get to it.
Created attachment 86241 [details] [review] Proposed patch The problem lies within the changed signal of the radio action, which is eventually emitted in the set_group() call. The code generated for the signal contains a line that should invoke the C++ default signal handler and that looks roughly like this: obj->on_changed(Glib::wrap(p1)); where p1 is a GtkRadioAction*, in this case the same object as the object obj wraps. Glib::wrap() creates a temporary Glib::RefPtr<Gtk::ActionGroup> that decreases the reference count of p1 eventually without ever having refed it. The patch now calls Glib::wrap(p1, true) to take an additional reference. It also moves the conversion macro to radioaction.hg because other places might need a conversion without an own reference (however, currently this is the only place where such a conversion is ever required). I wonder whether there are similar situations with other signals in gtkmm.
Excellent. Please apply to svn trunk. You might remove the conversion from the general .m4 conversion file, to see if any more signals need the same attention.
This is what I already did, but I thought of problems with other types.