bug-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: virtual table off by three problem


From: Aubrey Holland
Subject: Re: virtual table off by three problem
Date: 12 Feb 2002 15:07:13 -0800

OK, I finally figured it out.  I had a class definition like this:

class A
{
        virtual void a();
#ifdef NEEDED_DEFINE
        virtual void b();
#endif
        virtual void c();
};

When I compiled the library that contained this class, I did not
define NEEDED_DEFINE.  However, when I compiled the application that
used the library, I did define it.  I believe that this created a
mismatch between the virtual table generated with the library and what
was expected by the application.  Hope this helps.

Aubrey

address@hidden (Aubrey Holland) wrote in message news:<address@hidden>...
> Here's what I've learned....
> 
> 1) This only happens if the object being called is allocated on the
> heap.  Declaring a local variable and then making calls to it works
> just fine.
> 
> 2) The problem can be fixed by maintaining a consistent ordering of
> virtual methods throughout the class hierarchy.  For example, if we
> saw this problem in the following example:
> 
> class A
> {
>       virtual void a();
>       virtual void b();       
> };
> 
> class B : public A
> {
>       virtual void c();
>       virtual void b();
>       virtual void a();
> };
> 
> then we could solve the problem simply by reorganizing the declaration
> of a, b, and c in class B so that they follow the order declared in
> class A with new ones at the end.  e.g.
> 
> class B : public A
> {
>       virtual void a();
>       virtual void b();
>       virtual void c();
> };
> 
> I attempted to write a simple test application that would exhibit this
> problem with no luck, so I think there must be something else
> involved.  Also, we have plenty of classes where we haven't worried
> about the ordering and there is only one place where I've seen this
> problem.
> 
> Mark, I'd be interested to hear if you learn anything new about this
> or if it's fixed in the 3.0 builds.  I'm concerned about finding
> further problems if we move to 3.0 at this point.
> 
> Aubrey Holland
> 
> 
> 
> address@hidden (Marc Brett) wrote in message news:<address@hidden>...
> > Me too.
> > We're getting the same behaviour with g++ 2.95.2 and Redhat 6.2,
> > SGI workstation with single processor Pentium III.
> > Trying to recompile with g++ 3.0.2, but this may take some time.
> > 
> > Would be interested to hear if you make any progress.
> > 
> > Aubrey Holland <address@hidden> wrote:
> > > In one of my libraries, I have a rather deep inheritance tree where
> > > the classes in this tree contain quite a few virtual functions.  I
> > > have noticed recently that there seems to be a problem with the
> > > virtual tables that get created for some of these classes. 
> > > Specifically, when I try to call one of the virtual methods in this
> > > class, the result is that I get a call to the virtual method that is
> > > three virtual methods down in the header file.  I.e. in the following
> > > overly-simplified example, a call to a() would result in d() actually
> > > being called.  This happens regardless of where I place the function
> > > in the header file... the third one down is always called.
>  
> > > class example
> > > {
> > >     virtual void a();
>  
> > >     void nonvirtual();
>  
> > >     virtual void b();
> > >     virtual void c();
> > >     virtual void d();
> > > };
>  
> > > I saw the following previous similar posting, but it seems to indicate
> > > the the bug is already fixed:
>  
> > > http://groups.google.com/groups?q=g%2B%2B+virtual+table+off+by&hl=en&selm=Pine.OSF.3.91j.950911160602.5228N-100000%40saul6.u.washington.edu&rnum=3
>  
> > > I'm working on trying to reproduce this in a smaller, more portable
> > > example program but haven't had much luck as of yet.
>  
> > > Sysyem info:
>  
> > > Dual processor Dell Workstation, running Pentium Xeon processors.
> > > RedHat 7.2
> > > gcc and g++ 2.96-98
>  
> > > TIA,
> > > Aubrey Holland



reply via email to

[Prev in Thread] Current Thread [Next in Thread]