GNOME Bugzilla – Bug 92208
Unable to inherit from items
Last modified: 2004-12-22 21:47:04 UTC
Using gnomecanvasmm 1.3.9-1 and gtkmm 1.3.20-1 from Debian Sid (both built from debian sources) I am unable to inherit from items and extend them with additional data members. A br0ken example is attached. I've tried looking into the problem a bit and I found a 'this' equal to 0x00000001. Surely my memory isn't being allocated in the kernel's space :) Hopefully you will be able to reproduce the bug easily (you may have to use electric fence). If not, I'll provide you with debugger information or give someone a shell account on my box to use for testing.
Created attachment 10828 [details] C++ source demonstrating the bug
I've tested the attached code and my program with the CVS versions of gtkmm and gnomecanvasmm with simular outcomes. The attached sample now runs, but if linked with electric fence, segfaults. My program segfaults even more surely. Looking at the backtraces I see that in both cases the segfault happens in the constructor of the derived class. If no one is unable to reproduce the bug, I can provide backtraces and such, but if the bug is that obscure I doubt anyone can fix it from a backtrace anyway :(
Thanks for the report. This _might_ be related to this gcc 2.9* compiler bug: http://bugzilla.gnome.org/show_bug.cgi?id=78578 Can you find a similar workaround for these classes?
From what I've read about the possible compiler bug, it seems quite likely and matches up quite nicely to what I've observed in gdb. I have no way to verify, however. I've exchanged some emails with ERDI "cactus" Gergo about this bug, and he was unable to reproduce it. The other guy I'm working on the project with could reproduce the bug, and I've sent inqueries as to the compilers used to each. If anyone with gcc 3.2 or so could please test, we might get some idea of what's going on. As for a fix for the problem, I can't think of any workaround. Damn gcc sucks... Perhaps if someone could point me towards the specific dynamic_cast that's causing the problem I could rewrite it with static casts? I can't really require gcc 3.2, and I can't avoid inheriting without major troubles, so any ideas would be much apreciated :)
I have looked the Gnome::Canvas::Text class that you use in your example code. There is an alternative constructor. You could then just set the properties in your own constructor. That's what the other constructor does anyway (though you should use property_*.set_value() rather than set(...)). As long as these workarounds exist then I think I don't think this is critical, even though I use the same broken compiler. As for dynamic_cast<>, it's in the singal callbacks. You should see it in the backtrace. It's generated by tools/m4/signal.m4. I can't remember exactly why we use it - I seem to remember that it was the only way (or most convenient way) to cast when using multiple inheritance with virtual base classes. It would be nice to double-check that and add more comments if possible. That .m4 file currently has this comment, but it doesn't make perfect sense to me now: dnl We have to use a dynamic_cast because we do not dnl know the actual type from which to cast up. CppObjectType *const obj = dynamic_cast<CppObjectType*>( Glib::ObjectBase::_get_current_wrapper`'((GObject*)$8));
Please do tell us whether using that other constructor fixes this bug for you.
I'm about to close this bug because you have not replied, and because it looks like the work around should work for you.
Heh...sorry it's taken me so long to reply. I have not tried the work arounds, but I will shortly. I did, however, try building it with gcc 3.2, and this problem seems to have gone away. Getting gcc 3.2 to work required me to buy a new HD and install gentoo linux on it, and this is why I've been so slow. I'll try the workaround soon, but atm I'm busy looking for a job. I'm fairly confident that this is the same compiler bug mentioned before, so the workarounds should work around.
I have added an FAQ entry about this.