Serious bug in VC++.NET 2003 -- invalid v-table

  • Thread starter Thread starter Colonel Kernel
  • Start date Start date
C

Colonel Kernel

I've found what seems to be a very serious (although obscure) bug in
VC++.NET 2003 when using Loki's class hierarchy-generation facilities.
The compiler seems to generate an invalid v-table for my class, which
causes virtual method calls to dispatch incorrectly, causing run-time
errors and crashes. The problem seems to occur because the compiler
doesn't catch the case where I give a template method the same name as
a virtual method defined elsewhere in the same hierarchy.

I have a repro ready to go. It's about as simple as I can make it, but
familiarity with Loki's GenScatterHierarchy and GenLinearHierarchy is
essential to understanding what's going on. Loki is required for the
repro (http://sourceforge.net/projects/loki-lib). If anyone is
interested in the repro (MSVC++ team, take note!), please e-mail me
at:

c_kernel at hotmail dot com

I couldn't find a KB article about this problem, so I assume I'm the
first to find it (lucky me). Although there seems to be a simple
workaround for this instance of the bug, its symptoms are very, very
serious. I urge everyone to watch out for it, and I urge those
responsible to get a fix out ASAP.

Bruce Johnston
Simba Technologies Inc.
www.simba.com
 
An update: I've created a (somewhat) simpler repro that doesn't rely
on Loki. If anyone is interested, please e-mail me.
 
Colonel Kernel said:
An update: I've created a (somewhat) simpler repro that doesn't rely
on Loki. If anyone is interested, please e-mail me.
Click to expand...

could you post simplest repre code here ? I'm just curious (I know MC++D
book).


B.
 
Colonel said:
An update: I've created a (somewhat) simpler repro that doesn't rely
on Loki. If anyone is interested, please e-mail me.
Click to expand...

You can post the code here, or email it to me (remove the obviously
removeable parts of my email address). If it repros for me and looks like a
bug (not some obscure undefined behavior) I'll get it into the bug pipeline.

-cd
 
I simplified the repro even further. Now it's actually small enough to post.
:)

I've already been in contact with the VC++ team via e-mail since yesterday,
so they have this repro already. But here it is anyway, for those who are
curious:

---------------------------------------------------
#include <iostream>


// All this code is an "unrolling" of Loki's class-hierarchy generation
// techniques. I've removed as much template stuff as possible in order to
// isolate the bug as much as possible. Keep in mind that this a repro, not
a
// motivating example. The pattern of inheritance and template instantiation
// that is in this repro occurs somewhat frequently when generating class
// hierarchies using Loki.


// Uncomment this to reproduce the bug.
//#define SHOWBUG


class Interface
{
public:

// This level of delegation is required in order to reproduce the bug.
// main() can't just call doFoo directly, or the bug won't occur.
void foo( int i )
{
this->doFoo( i ) ;
}

protected:

virtual void doFoo( int i ) = 0 ;

virtual ~Interface() {}
} ;



// This class must take its base class as a template parameter in order for
// the bug to occur.
template <class IFace>
class IntermediateBase : public IFace
{
protected:

// This operation needs to be in this intermediate base class in order
// for the bug to occur. Also, it needs to be a template. I think the
// fact that it is a template method with the same name as a virtual
// method in a class hierarchy that is established via template
paramters
// (see IFace above) is the key circumstance of this bug.
template <class T>
#ifndef SHOWBUG
void doFooImpl( T t )
#else
void doFoo( T t )
#endif
{
std::cout << typeid( t ).name() << ": " << t << std::endl ;
}
} ;



class Implementation : public IntermediateBase<Interface>
{
typedef IntermediateBase<Interface> Base ;

protected:

void doFoo( int i )
{
#ifndef SHOWBUG
this->Base::doFooImpl<int>( i ) ;
#else
this->Base::doFoo<int>( i ) ;
#endif
}
} ;



int main()
{
Implementation impl ;

impl.foo( 1 ) ;

return 0 ;
}
 
Colonel said:
I simplified the repro even further. Now it's actually small enough
to post. :)

I've already been in contact with the VC++ team via e-mail since
yesterday, so they have this repro already. But here it is anyway,
for those who are curious:
Click to expand...

Thanks for sharing, and for taking the time to narrow down a concise repro
case - it really makes a difference in getting bugs like this fixed.

-cd
 
Back
Top