Menu
▾
▴
[Opencxx-users] Re: [opencxx] Another question regarding double inheritance
|
From: Grzegorz J. <ja...@he...> - 2002-11-07 01:36:51
|
On 6 Nov 2002, Francois Taiani wrote:
> 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.
OK, thanks.
Grzegorz
>
> 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
>
>
>
##################################################################
# 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. #
##################################################################
|
