Menu
▾
▴
[Opencxx-users] Re: [opencxx] Another question regarding double inheritance
|
From: Francois T. <fra...@la...> - 2002-11-06 17:13:36
|
Hi Grzegorz,
thanks for having check the testcase against current CVS.
> 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?
I'll try to do it, though given my high personal "context switch rate",
I don't promise to be very performant. As soon as I've tested your fix,
I'll let you know what the results are.
Cheers
Francois
On Wed, 2002-11-06 at 09:47, Grzegorz Jakacki wrote:
> 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. #
> ##################################################################
--
Francois Taiani +33 (0) 5 6133 6406
LAAS-CNRS (http://www.laas.fr) Dependable Computing
http://www.laas.fr/~ftaiani and Fault Tolerance
|
