GNOME Bugzilla – Bug 341895
gtkmm 2.8.6/2.8.7 are utterly hosed
Last modified: 2006-05-19 18:14:48 UTC
Oh dear. The changes to remove internal dependencies on the property methods seem to have gone very very very badly wrong. One example: in actiongroup.ccg: const gchar* action_name = (char*)g_object_get_data(G_OBJECT(action->gobj()), "name"); was introduced, but the "name" is a gobject property and not named data, so g_object_get(G_OBJECT(action->gobj()), "name", &action_name, NULL); would be the correct call to make. This wrong call results in a NULL return value causing a crash in the subsequent string concatenation. I'm now following up on another crash related to Gtk::Entry and/or Gtk::Editable. I currently cannot say how many problems have been introduced, but I will continue investigating.
I've found another problem as I trawl through the diff: Gtk::Window::set_default_icon's implementation has been truncated to a single ';' - unsurprisingly, it doesn't do much right now. More to come.
I count an addition 16 changes of this type in the diff.
Those cases are all in the autogenerated code. The entry in gtk_methods.defs seems correct but the generated code consistently has the empty function body. I can't currently see any pattern in the affected methods to explain why there were singled out. Some take parameters, some take none. Lots of different types. It's all very strange. I currently can't say if the crash in Gtk::Entry usage is due to these missing method implementations but it seems likely - there are very few actual code changes.
Ok, the empty function bodies are comming from changes to mmproc in glib. I just regenerated the 2.8.5 set with glibmm 2.10.2 and they were similarly broken.
Aha, I've been having an odd crash in glom. I'll get on it.
The empty methods should be fixed by the fix I just made to glibmm/tools/m4/convert_base.m4.
The g_object_get_data()/g_object_get() fix is in CVS too. Many thanks.
Does this seem better now?
The two identified problems do indeed appear to be fixed. However, they have uncovered an even nastier problem. In a nutshell, what I see is that when I attempt to call a method that is really a gobject virtual method on a non-gtkmmproc derived subclass, everything goes to hell in a handbaskest and the vtable lookup to find the c++ virtual method goes wrong and calls a different method from what it should - as in it calls the next method in the table! This is happening with libview specifically and only when dynamically linked. If I statically link the subclass into my test case, it works correctly. It makes no difference if I recompile libview against the latest glibmm/gtkmm or if I use my previous binary. This did not happen with 2.10.1/2.8.5. Valgrind doesn't not report any invalid accesses before everything blows up when the wrong method is called. I will continue trying to narrow this down but it's very very evil.
I rebuilt gtkmm 2.8.5 against glibmm cvs and my testcase doesn't crash, so the cause is a gtkmm change. I guess that's good news.
Ok, it's the obvious guilty change. The change in editable.hg that replaced the _VFUNC_H(insert_text_vfunc, void, `const Glib::ustring& text, int& position') with virtual void insert_text_vfunc(const Glib::ustring& text, int& position); is the cause of the problem. Reverting that fixed the crash. In my specific case, the attempt to call delete_text_vfunc was going off the deep end and calling get_chars_vfunc instead. We can see why this would happen from looking at the generated editable.h. insert_text_vfunc has been reordered below all the other vfuncs. So, an existing binary would still call at the delete_text_vfunc offset, but now get get_chars_vfunc - as we observe. I can't explain why my rebuilt libview still crashed though - maybe I didn't really rebuild it or something else silly went wrong. Anyway, the correct fix is either to revert the change or to redo it in such a way that the method declaration order does not change.
Other headers that were tweaked so that method reordering might have occured: pixbuf.hg pixbufloader.hg celllayout.hg treeviewcolumn.hg
Further investigation reveals: pixbuf.hg: Not reodered. Function bodies look correct. celllayout.hg treeviewcolumn.hg New add_attribute method shifts method offsets. pixbufloader.hg: The new header is not reordered but write() and close() have useless function bodies. The exception management boilerplate is present but not the function call itself. There may be additional uses of whatever generation template produced these bodies, but it's hard to see. More seriously, I cannot guarantee that there are not additional classes of generated method that are not flawed but which have yet to be observed. It's a large diff to trawl through. But for now, with these known problems fixed, I am not observing any other negative symptoms.
Damn, vfunc reordering. Didn't think of that. I'll take care of it, adn the other strangeness, and review the complete diff again. Many thanks.
> editable.hg: Fixing now. > celllayout.hg > treeviewcolumn.hg > > New add_attribute method shifts method offsets. These are not virtual methods, so there should be no offset issues.
> editable.hg Fixed. > pixbufloader.hg: > The new header is not reordered but write() and close() have useless function bodies Fixed. (Affected every void returning method that threw exceptions.)
I rebuilt and tested with the latest glibmm and gtkmm-2-8 and everything seems to be in order again. I obviously can't be sure that there isn't something else hidden in there, but it's looking good so far. Thanks!
Everything seems OK. I've released new versions.
Are you going to release a 2.8.8? I only see a new glibmm and gtkmm 2.9.x.
Any moment now.