After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 158040 - RTTI problem with Visual Studio 2003
RTTI problem with Visual Studio 2003
Product: glibmm
Classification: Bindings
Component: object
Other Windows
: Normal normal
: ---
Assigned To: gtkmm-forge
Depends on:
Reported: 2004-11-12 13:41 UTC by Cedric Gustin
Modified: 2006-05-24 07:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

Testcase for RTTI bug in Visual Studio 2003 (1017 bytes, text/plain)
2004-11-12 13:44 UTC, Cedric Gustin
RTTI + virtual inheritance: crash with MSVC example (1.71 KB, text/plain)
2004-11-13 19:42 UTC, Cedric Gustin
Details (6.64 KB, application/zip)
2004-11-17 13:05 UTC, Murray Cumming

Description Cedric Gustin 2004-11-12 13:41:48 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.
Comment 1 Cedric Gustin 2004-11-12 13:43:11 UTC
Here is a pure glibmm example that reproduces the problem.

Visual Studio : offset between memory spaces in base constructor
g++ : no offset (expected result)
Comment 2 Cedric Gustin 2004-11-12 13:44:36 UTC
Created attachment 33703 [details]
Testcase for RTTI bug in Visual Studio 2003
Comment 3 Cedric Gustin 2004-11-13 19:41:35 UTC
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 ?
Comment 4 Cedric Gustin 2004-11-13 19:42:49 UTC
Created attachment 33737 [details]
RTTI + virtual inheritance: crash with MSVC example
Comment 5 Cedric Gustin 2004-11-16 12:46:36 UTC
Ok, it seems this bug is not limited to MSVC.

For a discussion of the standards

Karl Nelson submitted a bug ages ago against gtk-- and gcc-2.95.2 (which was
fixed in gcc-3.0)

More importantly, The MSVC developing team is aware of the problem

I guess there is nothing else we can do except to redirect gtkmm+MSVC potential
users to this workaround

which is definitively ugly...
Comment 6 Murray Cumming 2004-11-17 08:19:16 UTC
If this is such a similar bug, won't the workaround here work for this too?:

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?
Comment 7 Cedric Gustin 2004-11-17 12:52:49 UTC
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
Comment 8 Murray Cumming 2004-11-17 13:02:18 UTC
Here is a simplified test case with a project file. It's probably very similar
to the MSDN one.
Comment 9 Murray Cumming 2004-11-17 13:05:50 UTC
Created attachment 33881 [details] 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
Comment 11 Murray Cumming 2005-02-01 15:32:43 UTC
Note that MS say that they have fixed this in the next major release of Visual C++. 
Comment 12 Johan Boule 2005-04-04 16:43:07 UTC
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

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.
Comment 13 Johan Boule 2005-11-11 17:02:54 UTC
they released the non beta verson, this bug should be check for again
Comment 14 Cedric Gustin 2005-11-16 20:35:46 UTC
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.
Comment 15 Murray Cumming 2006-05-24 07:30:26 UTC
So, this seems to be fixed.