Ok. I can live with it for time being .. thanks ..
-Art
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:
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.
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 - 21:30:18 CET
This archive was generated by hypermail 2.2.0 : Sat Feb 11 2012 - 05:50:02 CET