[Opencxx-users] Re: [opencxx] Another question regarding double inheritance

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On 4 Nov 2002, Francois Taiani wrote:

> Hi Grzegorz
>
> I'm using OpenC++ version 2.5.12, along with gcc 2.95.4, libc6 2.2.5,
> and libstdc++ 2.10. My machine runs Linux kernel 2.4.18 on a pentium
> III.

I tried on HEAD version from CVS, the bug is still there.

What I have found (line numbers according to HEAD):

(1) I found simpler testcase:

    class A{};
    namespace N
    {
        class B { };
        class A : public ::A, public B
        {};
    }

(2) There is a bug in lookup of base classes. OpenC++ merely ignores the
    scope. Thus in the testcase above it links class 'A' (not '::A'!) as
    base of 'A', so when it comes to finding 'B' the lookup starts
    from the current scope (this is also a little bit strange), which is
    class 'A', and proceeds first to base classes, and here it is looping
    forever.

(3) IMHO it is enough to fix lookup for base classes, namely:

env.cc:100     else{
env.cc:101         int len;
env.cc:102         Environment* e = this;
env.cc:103         char* base = Encoding::GetBaseName(name->GetEncodedName(), len, e);

    gets name proper into 'base' and environment corresponding
    to scope into 'e', but does not use 'e' any more!!!

env.cc:104         if(base != nil && e != nil)
env.cc:105             if(LookupType(base, len, bind))
                                     ^^^^
           perhaps just this should be 'e'

env.cc:106                 if(bind != nil){
env.cc:107                     bind->GetType(tinfo, this);
env.cc:108                     return tinfo.ClassMetaobject();
env.cc:109                 }

I am sorry, but at the moment I do not have time to check if this is a real
fix. If somebody can pick it up (add testcase, try this fix, run tests,
commit if ok), please do. Francois, can you track this bug and make sure
that eventually the fix is checked in?

Let me know if any issues.

Regards
Grzegorz

>
> Cheers
>
> Francois
>
> On Mon, 2002-11-04 at 10:05, Grzegorz Jakacki wrote:
> >
> > Hi,
> >
> > Which version of OpenC++ does it?
> >
> > Regards
> > Grzegorz
> >
> > On 1 Nov 2002, Francois Taiani wrote:
> >
> > > Hi again,
> > >
> > > I'm applying OpenC++ on a program with namespaces and double
> > > inheritance, and occ seems to have troubles when it encounters the
> > > following pattern: (which compile correctly with "g++ -c".)
> > > --
> > > class A{};
> > > namespace N
> > > {
> > >   class B { };
> > >   class A : virtual public ::A, virtual public B
> > >   {};
> > > }
> > > --
> > > If I launch occ on this bit of code (here for instance with the default
> > > metaclass Class), I get a segmentation fault:
> > > --
> > > $ /usr/bin/occ -E -SClass test2.cc
> > > zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
> > > --
> > > I've used gdb to investigate what was going on and it seems occ is
> > > trapped in an infinite recursion. Below is what the bottom of the stack
> > > looks like just after the segfault. Environment::SearchBaseOrUsing ()
> > > and Environment::LookupType() recursively call each other until the
> > > memory space available to the stack gets exhausted.
> > > ---
> > > <--snip-- Infinite recursion leading to segmentation fault-->
> > > ..
> > > #32640 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32641 0x080693c9 in Environment::LookupType ()
> > > #32642 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32643 0x080693c9 in Environment::LookupType ()
> > > #32644 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32645 0x080693c9 in Environment::LookupType ()
> > > #32646 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32647 0x080693c9 in Environment::LookupType ()
> > > #32648 0x080692bb in Environment::LookupClassMetaobject ()
> > > #32649 0x0806af6f in Walker::RecordBaseclassEnv ()
> > > #32650 0x08085764 in ClassWalker::RecordMembers ()
> > > #32651 0x08085245 in ClassWalker::TranslateClassSpec ()
> > > #32652 0x0806c799 in Walker::TranslateClassSpec ()
> > > #32653 0x08062904 in PtreeClassSpec::Translate ()
> > > #32654 0x0806b014 in Walker::Translate ()
> > > #32655 0x0806d72d in Walker::TranslateTypespecifier ()
> > > #32656 0x0806b8d3 in Walker::TranslateDeclaration ()
> > > #32657 0x08062440 in PtreeDeclaration::Translate ()
> > > #32658 0x0806b014 in Walker::Translate ()
> > > #32659 0x0806c3a8 in Walker::TranslateBrace ()
> > > #32660 0x08062244 in PtreeBrace::Translate ()
> > > #32661 0x0806b014 in Walker::Translate ()
> > > #32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
> > > #32663 0x08062394 in PtreeNamespaceSpec::Translate ()
> > > #32664 0x0806b014 in Walker::Translate ()
> > > #32665 0x0805de0a in Compile ()
> > > #32666 0x0805db2a in Compile ()
> > > #32667 0x0805d941 in Compile ()
> > > #32668 0x0805d834 in Compile ()
> > > #32669 0x0805d7b4 in main ()
> > > #32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
> > > ---
> > > Interstingly, the segfault disappears if I remove any of the base
> > > classes of N::A. For instance occ works fine on
> > > --
> > > class A{};
> > >
> > > namespace N
> > > {
> > >   class B { };
> > >   class A : virtual public ::A // , virtual public B
> > >   {};
> > > }
> > > --
> > > The problem also disappears if I use another name for N::A (one that
> > > does not mask ::A). I think this is a bug, but I'm not sure. Would
> > > someone have any comment on it ?
> > >
> > > Thanks in advance
> > >
> > > Francois
> > >
> > > --
> > > Francois Taiani                 +33 (0) 5 6133 6406
> > > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > > http://www.laas.fr/~ftaiani     and Fault Tolerance
> > >
> > >
> > >
> >
> > ##################################################################
> > # Grzegorz Jakacki                       Huada Electronic Design #
> > # Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
> > # tel. +86-10-64365577 x2074               Beijing 100015, China #
> > # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
> > ##################################################################
> --
> Francois Taiani                 +33 (0) 5 6133 6406
> LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> http://www.laas.fr/~ftaiani     and Fault Tolerance
>
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################