Re: Bug or feature?

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Thu, 9 Feb 2012 13:33:29 -0600


Hi Heather, Art,

So, it is very likely that we fixed this problem in more recent version of ROOT :). Since there is a simple work-around, we do not plan on updating v5.26 for this issue.

Cheers,
Philippe.

On 2/3/12 1:58 PM, Heather Kelly wrote:
> To be more precise, Fermi is currently using:
>
> *******************************************
> * *
> * W E L C O M E to R O O T *
> * *
> * Version 5.26/00a 19 January 2010 *
> * *
> * You are welcome to visit our Web site *
> * http://root.cern.ch *
> * *
> *******************************************
>
> ROOT 5.26/00a (tags/v5-26-00a_at_32053, Jan 19 2010, 12:43:52 on linux)
>
> CINT/ROOT C/C++ Interpreter version 5.17.00, Dec 21, 2008
>
>
> Which admittedly is older, and we are planning an upgrade in the next few months.
>
> Take care,
> Heather
>
> On Fri, Feb 3, 2012 at 2:46 PM, Snyder, Arthur E. <snyder_at_slac.stanford.edu <mailto:snyder_at_slac.stanford.edu>> wrote:
>
> CINT/ROOT C/C++ Interpreter version 5.17.00, Dec 21, 2008
>
> This is version used by Fermi space telescopy. Does look kind of old.
>
>
>
> ________________________________________
> From: Philippe Canal [pcanal_at_fnal.gov <mailto:pcanal_at_fnal.gov>]
> Sent: Friday, February 03, 2012 11:37 AM
> To: Snyder, Arthur E.
> Cc: roottalk_at_root.cern.ch <mailto:roottalk_at_root.cern.ch>
> Subject: Re: [ROOT] Bug or feature?
>
> Hi Art,
>
> I can not reproduce the problem with the trunk. Which version of ROOT are you using?
>
> Cheers,
> Philippe.
>
> PS. How do you assert the 2 have the same location? Recently we updated the implementation
> of TString to go from a sharing of the internal (delay-copy-until-write) to a more efficient non-shared implementation.
>
> On 2/3/12 1:28 PM, Snyder, Arthur E. wrote:
> > Dear rooters
> >
> > When I do the following with TStrings
> >
> > TString ybest=yyvar;
> >
> > It does NOT create new string and copy string yyvar into it, but instead sets&yybest=&yyvar. As my intended purpose was to
> keep a copy of "best" while doing something else with yyvar this was very confusing. yybest kept being "overwritten" by the
> new string
> >
> > If I do
> >
> > TString ybest;
> > ybest=yyvar;
> >
> > It works as it should.
> >
> > This is not good C++. Is this a cint bug or feature?
> >
> > Pehaps it's related to the problem with static strings below ...
> >
> > The same problem does not occur with int's. They behave as expected ...
> >
> > -Art
> >
> >
> >
> > ________________________________________
> > From: Philippe Canal [pcanal_at_fnal.gov <mailto:pcanal_at_fnal.gov>]
> > Sent: Friday, August 20, 2010 9:55 AM
> > To: Snyder, Arthur E.
> > Cc: Fons Rademakers; Rene Brun; mbellis_at_stanford.edu <mailto:mbellis_at_stanford.edu>; Paul Russo
> > Subject: Re: [ROOT] Re: problem with compiled statics in root
> >
> > Hi Art,
> >
> > Yes, we suspect a problem with accessing/setting the static variable in the interpreter ... We will look into it.
> >
> > Cheers,
> > Philippe.
> >
> > On 8/20/10 11:48 AM, Arthur E. Snyder wrote:
> >> This worked!
> >>
> >> #include "rootLib/Common.hh"
> >> void xx()
> >> {
> >> Common::project="x";
> >> }
> >>
> >> I had to explicit include Common.hh, but with that change. It didn't crash and
> >>
> >> root [7] Common::project
> >> (class TString)"x"
> >>
> >> so that looks right.
> >>
> >> However,
> >>
> >> root [8] Common::project="y"
> >> *** glibc detected *** double free or corruption (out): 0x02c78950 ***
> >>
> >> (not suprisingly) still crashes.
> >>
> >>
> >> So I guess, as you said, this test indicates an intrepreter problem.
> >>
> >>
> >>
> >> A.E. Snyder, Group EC \!c*p?/
> >> SLAC Mail Stop #95 ((. .))
> >> Box 4349 |
> >> Stanford, Ca, USA, 94309 '\|/`
> >> e-mail:snyder_at_slac.stanford.edu <mailto:e-mail%3Asnyder_at_slac.stanford.edu> o
> >> phone:650-926-2701 <tel:650-926-2701> _
> >> http://www.slac.stanford.edu/~snyder <http://www.slac.stanford.edu/%7Esnyder> BaBar
> >> FAX:650-926-2657 <tel:650-926-2657> Collaboration
> >>
> >>
> >>
> >> On Fri, 20 Aug 2010, Fons Rademakers wrote:
> >>
> >>> Yes, so that there is no interpreted code. Thus make a small script containing:
> >>>
> >>> void xx()
> >>> {
> >>> Common::project="x"
> >>> }
> >>>
> >>> which you run via
> >>>
> >>> .x xx.C+
> >>>
> >>> Do you still get:
> >>> *** glibc detected *** double free or corruption (out): 0x07c12950 ***
> >>>
> >>>
> >>> Cheers, Fons.
> >>>
> >>>
> >>>
> >>> On 20/08/10 18:32, Arthur E. Snyder wrote:
> >>>> Hi Fons,
> >>>>
> >>>> I haven't tried it with AClicC. By this you mean compile a macro with a
> >>>> static using the .L macro.C+ (or ++) rather then with gmake that makes my
> >>>> library libAES.so?
> >>>>
> >>>> -Art
> >>>>
> >>>> PS. If you're on vacation this can wait ..
> >>>>
> >>>> A.E. Snyder, Group EC \!c*p?/
> >>>> SLAC Mail Stop #95 ((. .))
> >>>> Box 4349 |
> >>>> Stanford, Ca, USA, 94309 '\|/`
> >>>> e-mail:snyder_at_slac.stanford.edu <mailto:e-mail%3Asnyder_at_slac.stanford.edu> o
> >>>> phone:650-926-2701 <tel:650-926-2701> _
> >>>> http://www.slac.stanford.edu/~snyder <http://www.slac.stanford.edu/%7Esnyder> BaBar
> >>>> FAX:650-926-2657 <tel:650-926-2657> Collaboration
> >>>>
> >>>>
> >>>>
> >>>> On Fri, 20 Aug 2010, Fons Rademakers wrote:
> >>>>
> >>>>> Hi Art,
> >>>>>
> >>>>> does this also happen when compiling a macro via ACliC accessing the
> >>>>> TString statics? If that works it is most likely an interpreter issue. If
> >>>>> not you should be able to make a small standalone compiled program showing
> >>>>> this problem.
> >>>>>
> >>>>> Cheers, Fons.
> >>>>>
> >>>>>
> >>>>> On 20/08/10 18:16, Rene Brun wrote:
> >>>>>> Dear Art,
> >>>>>>
> >>>>>> Many of us are on holidays. I had assigned this problem to Fons and
> >>>>>> Philippe, hoping that one of them will answer
> >>>>>> if they are still alive ::)
> >>>>>>
> >>>>>> Rene
> >>>>>>
> >>>>>> Arthur E. Snyder wrote:
> >>>>>>>
> >>>>>>> Dear Rene et al.,
> >>>>>>>
> >>>>>>> So far I've not gotten your usual rapid response about this problem ..
> >>>>>>> perhaps because I again got the subject line wrong .. so I'll re-post it.
> >>>>>>>
> >>>>>>> It is a very odd problem. All statics accept TStrings seem to work fine
> >>>>>>> and TString work too if I refer to them indirectly via a reference or
> >>>>>>> pointer.
> >>>>>>>
> >>>>>>> This happened during rhel3->rhel4(or 5) linux transition at SLAC, but I
> >>>>>>> don't think it's directly do to that, but rather the result of changing
> >>>>>>> from root 5.14-00e to 5.26-00 .. I have however no rhel3 machine
> >>>>>>> available on which to go back and check that.
> >>>>>>>
> >>>>>>> -Art S.
> >>>>>>>
> >>>>>>> Orignal post:
> >>>>>>>
> >>>>>>> Dear Rooters,
> >>>>>>>
> >>>>>>> I problem has come up with static variables in my compiled code. They
> >>>>>>> crash when I try to change them from the command line, ever since I was
> >>>>>>> forced to change to linux rhel4 and update to root 5.26-00. They
> >>>>>>> previousl y have been working for years ...
> >>>>>>>
> >>>>>>> The problem only occurs when the static in question is a TString.
> >>>>>>> Integers, etc. work as expected.
> >>>>>>>
> >>>>>>> Consider this example from my "Common" block, a class consisting of a lot
> >>>>>>> of static variables.
> >>>>>>>
> >>>>>>> Common.hh has:
> >>>>>>>
> >>>>>>> class Common {
> >>>>>>> public:
> >>>>>>> Common();
> >>>>>>> ~Common(){};
> >>>>>>>
> >>>>>>> ....
> >>>>>>>
> >>>>>>> static TString project; // project name (for unique file names)
> >>>>>>>
> >>>>>>> ...
> >>>>>>>
> >>>>>>> };
> >>>>>>>
> >>>>>>> Common.cc has:
> >>>>>>>
> >>>>>>> TString Common::project="3SToHiggs";
> >>>>>>>
> >>>>>>> CommonLinkDef.h:
> >>>>>>>
> >>>>>>> #ifdef __CINT__
> >>>>>>>
> >>>>>>> #pragma link off all globals;
> >>>>>>> #pragma link off all classes;
> >>>>>>> #pragma link off all functions;
> >>>>>>>
> >>>>>>> #pragma link C++ class Common;
> >>>>>>>
> >>>>>>> #endif
> >>>>>>>
> >>>>>>> which was enough for me to be able to see and set Common::project.
> >>>>>>>
> >>>>>>> starting a root session:
> >>>>>>>
> >>>>>>> loading |libAES| .. loaded my library containg Common:root [0]
> >>>>>>>
> >>>>>>> Common::project
> >>>>>>> (class TString)"3SToHiggs"
> >>>>>>>
> >>>>>>> --so I can see it from the command line, but if I try to change it, I get:
> >>>>>>>
> >>>>>>> root [1] Common::project="x"
> >>>>>>> *** glibc detected *** double free or corruption (out): 0x07c12950 ***
> >>>>>>> yakut10~/trial41/analysis-42/workdir>
> >>>>>>>
> >>>>>>> Curiously, I can make a ref or pointer to it and then change it!
> >>>>>>>
> >>>>>>> root [4]
> >>>>>>>
> >>>>>>> Any attempt to change it directly cause crash (even after rProject is
> >>>>>>> created), but via reference I can do it! So it is there!
> >>>>>>>
> >>>>>>> Is there some change in how root handles statics that accounts for this?
> >>>>>>> I can work around it, but it's pain ... Is there a way to make statics
> >>>>>>> behave correctly?
> >>>>>>>
> >>>>>>> -Art S.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> A.E. Snyder, Group EC \!c*p?/
> >>>>>>> SLAC Mail Stop #95 ((. .))
> >>>>>>> Box 4349 |
> >>>>>>> Stanford, Ca, USA, 94309 '\|/`
> >>>>>>> e-mail:snyder_at_slac.stanford.edu <mailto:e-mail%3Asnyder_at_slac.stanford.edu> o
> >>>>>>> phone:650-926-2701 <tel:650-926-2701> _
> >>>>>>> http://www.slac.stanford.edu/~snyder <http://www.slac.stanford.edu/%7Esnyder> BaBar
> >>>>>>> FAX:650-926-2657 <tel:650-926-2657> Collaboration
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> Org: CERN, European Laboratory for Particle Physics.
> >>>>> Mail: 1211 Geneve 23, Switzerland
> >>>>> E-Mail: Fons.Rademakers_at_cern.ch <mailto:Fons.Rademakers_at_cern.ch> Phone: +41 22 7679248 <tel:%2B41%2022%207679248>
> >>>>> WWW: http://fons.rademakers.org Fax: +41 22 7669640 <tel:%2B41%2022%207669640>
> >>>>>
> >>> --
> >>> Org: CERN, European Laboratory for Particle Physics.
> >>> Mail: 1211 Geneve 23, Switzerland
> >>> E-Mail: Fons.Rademakers_at_cern.ch <mailto:Fons.Rademakers_at_cern.ch> Phone: +41 22 7679248 <tel:%2B41%2022%207679248>
> >>> WWW: http://fons.rademakers.org Fax: +41 22 7669640 <tel:%2B41%2022%207669640>
> >>>
>
>
Received on Thu Feb 09 2012 - 20:33:41 CET

This archive was generated by hypermail 2.2.0 : Thu Feb 09 2012 - 23:50:01 CET