Re: Bug or feature?

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Fri, 3 Feb 2012 13:37:56 -0600


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]
> Sent: Friday, August 20, 2010 9:55 AM
> To: Snyder, Arthur E.
> Cc: Fons Rademakers; Rene Brun; 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 o
>> phone:650-926-2701 _
>> http://www.slac.stanford.edu/~snyder BaBar
>> FAX: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 o
>>>> phone:650-926-2701 _
>>>> http://www.slac.stanford.edu/~snyder BaBar
>>>> FAX: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 o
>>>>>>> phone:650-926-2701 _
>>>>>>> http://www.slac.stanford.edu/~snyder BaBar
>>>>>>> FAX:650-926-2657 Collaboration
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Org: CERN, European Laboratory for Particle Physics.
>>>>> Mail: 1211 Geneve 23, Switzerland
>>>>> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
>>>>> WWW: http://fons.rademakers.org Fax: +41 22 7669640
>>>>>
>>> --
>>> Org: CERN, European Laboratory for Particle Physics.
>>> Mail: 1211 Geneve 23, Switzerland
>>> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
>>> WWW: http://fons.rademakers.org Fax: +41 22 7669640
>>>
Received on Fri Feb 03 2012 - 20:38:04 CET

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