GNOME Bugzilla – Bug 158040
RTTI problem with Visual Studio 2003
Last modified: 2006-05-24 07:30:26 UTC
dynamic_cast does not work correctly with Visual Studio 2003 when it is used in the constructor of a base class with class members, i.e. when the derived class has not been fully initialized yet. dynamic_cast returns a pointer with an offset proportional to the size of the class members in the derived class. As a result, any call to a base class method in the base class constructor generates an application crash.
Here is a pure glibmm example that reproduces the problem. Visual Studio : offset between memory spaces in base constructor g++ : no offset (expected result)
Created attachment 33703 [details] Testcase for RTTI bug in Visual Studio 2003
I can now confirm that this is a compiler bug. Here is a pure C++ example that reproduces the problem: in summary, the combined use of RTTI and virtual inheritance seems to be the main bottleneck. In glibmm, ObjectBase virtually inherits from sigc::trackable, and both Glib::Object and Glib::Interface from Glib::ObjectBase. Can this be avoided ?
Created attachment 33737 [details] RTTI + virtual inheritance: crash with MSVC example
Ok, it seems this bug is not limited to MSVC. For a discussion of the standards http://groups.google.be/groups?hl=en&lr=&selm=3D6418B6.2080800%40o.ca Karl Nelson submitted a bug ages ago against gtk-- and gcc-2.95.2 (which was fixed in gcc-3.0) http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00578.html More importantly, The MSVC developing team is aware of the problem http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=2cf13d49-af0f-49bc-baa1-403ebf5085c8 I guess there is nothing else we can do except to redirect gtkmm+MSVC potential users to this workaround http://lab.msdn.microsoft.com/productfeedback/ViewWorkaround.aspx?FeedbackID=FDBK13535#1 which is definitively ugly...
If this is such a similar bug, won't the workaround here work for this too?: http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html#id2543380 Also, we had an MSVC++ build in gtkmm 2.2, though I think that was a static build. Didn't that work without this problem?
The static MSVC builds of gtkmm 2.2 have the same problem. The workaround for gcc-2.95 works (this is basically a hack similar to the one I yesterday mentioned in the msdn link) but then I get warnings (ans possibly a memory leak) when the widget destructors are called (window.exe): GLib-GObject-CRITICAL **: file gtype.c: line 2491 (g_type_class_pe ek_parent): assertion `g_class != NULL' failed which means that a dynamic_cast also fails in one of the base class destructors. I guess you might have to wait till VS.Net 2005 is released before supporting gtkmm on MSVC, if the 'this pointer in virtual base class constructor' is ever fixed...
Here is a simplified test case with a project file. It's probably very similar to the MSDN one.
Created attachment 33881 [details] msvctest.zip msvctest.zip gives the following output: 1. Testing a Base object Inside constructor: this = 0012FEC0, dynamic_casted this = 0012FEC0 Outside constructor: this = 0012FEC0, dynamic_casted this = 0012FEC0 2. Testing a Derived object Inside constructor: this = 0012FEA8, dynamic_casted this = 0012FEAC dynamic_cast<> seems to have failed. Outside constructor: this = 0012FEA8, dynamic_casted this = 0012FEA8
Bug FDBK19963 has been opened on MSDN. http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=9c3cdcfd-b030-4a60-a9e9-f0460036c751
Note that MS say that they have fixed this in the next major release of Visual C++.
I've tried the test program in msvc 8 beta 2 and it still fails. At first, I tought it was because we had to pass some compiler option to enable the bug fix, but then i read on http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=2cf13d49-af0f-49bc-baa1-403ebf5085c8 [quote] Resolved as Fixed by Microsoft on 2005-03-23 at 10:53:09 This bug has been fixed for RTM of Whidbey. The fix won't be in Beta 2. [/quote]
they released the non beta verson, this bug should be check for again
I confirm that the MSVC bug is fixed in Visual Studio 2005 RTM. The drawback : The /vd2 flag is now required at compile time. Now, the next step is to build gtkmm... I will do that this weekend and see if this /vd2 flag generates any conflict with the GTK+ libraries.
So, this seems to be fixed.