Re: [ROOT] Win + dictionary init

From: Valeri Fine (fine@bnl.gov)
Date: Sat Jul 07 2001 - 01:05:31 MEST


> Let me guess, saying "unknown class TGX11" without saying "libTGX not found"
> before? (Which means it did load the lib, but didn't init the dict?)

  Yes it is very our observation.
  Our "observation" there is some memory corruption. 
  However we did not find the exact reason and place.
> 
> :-) Let's try to fix that.
> 
 We  have been spending  many hours with gdb hunting this problem.
 At least it is clear there is no Windows specific here.
 At the moment we must switch to do something else. 

Since we found it works with 3.00/06 we went back to this ROOT version.
I'll try to come back to hunt the problem latter.

Appreciate any idea

  My best regards, Valeri

> > -----Original Message-----
> > From: owner-roottalk@pcroot.cern.ch
> > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Valeri Fine
> > Sent: Friday, July 06, 2001 5:32 PM
> > To: Axel Naumann; Roottalk@Pcroot. Cern. Ch
> > Subject: Re: [ROOT] Win + dictionary init
> >
> >
> > We have near the same problem under Linux with ROOT 3.01.05
> > (There was no such problem with
> > 3.00/06)
> >
> > The ROOT-based  code dies calling gROOT-ProcessLineFAst as follows:
> >
> >
> >  void TApplication::LoadGraphicsLibs()
> >
> >  . . .
> >   gROOT->ProcessLineFast("new TGX11("X11", "ROOT interface to X11");");
> >
> >
> >  Switching ROOTSYS from 3.01/05 to 3.00/06 cures the probem.
> >
> >    Any idea ?
> >
> >   My best regards
> >                                     Valeri
> > ----- Original Message -----
> > From: "Axel Naumann" <axel@fnal.gov>
> > To: "Roottalk@Pcroot. Cern. Ch" <roottalk@pcroot.cern.ch>
> > Sent: Friday, July 06, 2001 4:23 PM
> > Subject: [ROOT] Win + dictionary init
> >
> >
> > > Hi,
> > >
> > > I still have this persistent problem with win and the
> > dictionary. Apparently
> > > the order of the instantiation of the globals is messed up
> > sometimes. Here
> > > is what's happening on my machine (which breaks the dictionary) when
> > > starting a program that links against root libraries:
> > >
> > > * a TROOT object is created
> > >   - this calls new TCint, which calls at some point
> > G__reset_setup_funcs(),
> > > here's the stack:
> > > ---
> > > G__reset_setup_funcs() line 163
> > > G__scratch_all() line 257
> > > G__main() line 646
> > > G__init_cint() line 350 + 19 bytes
> > > TCint::ResetAll() line 328 + 10 bytes
> > > TCint::TCint(const char * 0x101fd864, const char * 0x101fd84c) line 101
> > > ---
> > >
> > >   - now, G__call_setup_funcs() is called. Those are empty, as
> > none of the
> > > global G__cpp_setup guys is instantiated yet. Call stack:
> > > ---
> > > G__call_setup_funcs() line 129
> > > G__main() line 703
> > > G__init_cint() line 350 + 19 bytes
> > > TCint::ResetAll() line 328 + 10 bytes
> > > TCint::TCint(const char * 0x101fd864, const char * 0x101fd84c) line 101
> > > TROOT::TROOT(const char * 0x101fd830, const char * 0x101fd818,
> > void (void)*
> > > * 0x00000000) line 245 + 40 bytes
> > > ---
> > >
> > > * finally, the G__cpp_setup guys are called. But now it's too
> > late! TCint
> > > doesn't care anymore, it thinks it's done with its dictionary
> > > initialization, so G__call_setup_funcs is not called anymore.
> > Example for my
> > > first call of G__add_setup_func:
> > > ---
> > > G__add_setup_func() line 65
> > > LIBCORE! G__cpp_setup_initG__Base1::G__cpp_setup_initG__Base1(void) + 22
> > > bytes
> > > LIBCORE! G__cpp_setupG__Base1 + 105 bytes
> > > ---
> > >
> > > * and now my main() gets called. And the dictionary is empty.
> > >
> > > So THIS is the reason why sometimes even UInt_t was unknown to
> > Root. How can
> > > we fix this? How can we make sure all G__cpp_setups "register"
> > first, before
> > > cint calls the setup funcs? Or shall we call
> > G__call_setup_functs directly
> > > at some point? Or can I circumvent this by some magical permutaion on my
> > > link line?
> > >
> > > (Win 2000, Root since 3.00/something)
> > >
> > > Cheers, Axel.
> > >
> > >
> >
> >
> 
> 



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:51 MET