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
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:28:45 CET
This archive was generated by hypermail 2.2.0 : Fri Feb 03 2012 - 23:50:01 CET