[ROOT] Drawing vertical lines on histogram

Re: [ROOT] Drawing vertical lines on histogram

RE: [ROOT] Drawing vertical lines on histogram

Re: [ROOT] Drawing vertical lines on histogram

Re: [ROOT] a problem with TTreeCache

Hi Simon,

See the similar report on the ROOT forum
at <http://root.cern.ch/phpBB3/viewtopic.php?t=14082>
for further update.

Cheers,
Philippe.

On 1/18/12 10:58 AM, Szymon Gadomski wrote:
> Dear ROOT Developers,
> While reading data from our DPM Storage Element, using the
> rfio protocol, we have seen errors that seem to come from
> TTreeCache. Here is a report.
>
> The error message is:
>
> Error in <TRFIOFile::TRFIOFile>: error doing rfio_read
> Error in <TBranch::GetBasket>: File: 
>
rfio:///dpm/unige.ch/home/atlas/atlaslocalgroupdisk/user/wbell/data11_7TeV/user.wbell.data11_7TeV.00191239.physics_Muons.merge.NTUP_TOPMU.f413_m1019_p694_p722_thin0001_0001.111112032448/user.wbell.005705._00037.output.root 
> at byte:536958, branch:EF_e45_medium1, entry:459, badread=1, nerrors=1, basketnumber=1
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  vector::_M_range_check
> /var/spool/torque/mom_priv/jobs/1418590.grid07.unige.ch.SC: line 55: 6815 Aborted
>
> This happens when the Storage Element is busy. An 'error doing
> rfio_read' leads to 'std::out_of_range'. It looks like reading
> is not blocked when the process should be waiting for more data.
> Instead the process continues and crashes, printing errors due
> to corrupted data.
>
> In the user code we have the lines (m_tree is a TTree*):
>
> m_tree->SetCacheSize(104857600);
> TTreeCache::SetLearnEntries(1); // Stop learning after 1 entry is read.
> m_tree->AddBranchToCache(branchName,true);
>
> Removing all these lines makes the errors disappear.
> This is why we think there is a problem with the TTreeCache.
> We are using ROOT 5.30/05.
>
> Please let us know if any more information would be useful.
> Best regards,
> Szymon Gadomski
>

RE: [ROOT] Bug or feature?

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
>>

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]
> 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
>>>

RE: [ROOT] Bug or feature?

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]
Sent: Friday, February 03, 2012 11:37 AM
To: Snyder, Arthur E.
Cc: 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]
> 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
>>>

Re: [ROOT] a problem with TTreeCache

Thank you Philippe. We will be following the ROOT forum entry with great 
interest. The users of our DPM, at the Uni of Geneva, are working 
without the cache, which slows down the processing.

If we could setup a test, which would help you diagnose the problem, 
please let us know.
Best wishes
Simon

On 3/2/12 6:45 PM, Philippe Canal wrote:
> Hi Simon,
>
> See the similar report on the ROOT forum
> at <http://root.cern.ch/phpBB3/viewtopic.php?t=14082>
> for further update.
>
> Cheers,
> Philippe.
>
>
> On 1/18/12 10:58 AM, Szymon Gadomski wrote:
>> Dear ROOT Developers,
>> While reading data from our DPM Storage Element, using the
>> rfio protocol, we have seen errors that seem to come from
>> TTreeCache. Here is a report.
>>
>> The error message is:
>>
>> Error in <TRFIOFile::TRFIOFile>: error doing rfio_read
>> Error in <TBranch::GetBasket>: File:
>> rfio:///dpm/unige.ch/home/atlas/atlaslocalgroupdisk/user/wbell/data11_7TeV/user.wbell.data11_7TeV.00191239.physics_Muons.merge.NTUP_TOPMU.f413_m1019_p694_p722_thin0001_0001.111112032448/user.wbell.005705._00037.output.root
>> at byte:536958, branch:EF_e45_medium1, entry:459, badread=1,
>> nerrors=1, basketnumber=1
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): vector::_M_range_check
>> /var/spool/torque/mom_priv/jobs/1418590.grid07.unige.ch.SC: line 55:
>> 6815 Aborted
>>
>> This happens when the Storage Element is busy. An 'error doing
>> rfio_read' leads to 'std::out_of_range'. It looks like reading
>> is not blocked when the process should be waiting for more data.
>> Instead the process continues and crashes, printing errors due
>> to corrupted data.
>>
>> In the user code we have the lines (m_tree is a TTree*):
>>
>> m_tree->SetCacheSize(104857600);
>> TTreeCache::SetLearnEntries(1); // Stop learning after 1 entry is read.
>> m_tree->AddBranchToCache(branchName,true);
>>
>> Removing all these lines makes the errors disappear.
>> This is why we think there is a problem with the TTreeCache.
>> We are using ROOT 5.30/05.
>>
>> Please let us know if any more information would be useful.
>> Best regards,
>> Szymon Gadomski
>>

--

-- 
==================================================
Szymon GADOMSKI
Université de Genève, Section de physique
Département de physique nucléaire et corpusculaire
24, Quai Ernest-Ansermet, CH-1211 Genève 4

phone ++41 22 767 7935 (CERN)
or    ++41 22 379 6278 (DPNC)
==================================================

[ROOT] Access objects inheriting from TAttLine via TAttLine pointer

Hello ROOTers,

I like to access different objects which all inherit from TAttLine. As a 
simple example of what I want to do, take the following script where all 
objects are actually TLine instances:

void TLineTest()
{
   TObjArray Array;

   Array.Add( new TLine( 0, 0, 1, 1 ) );
   Array.Add( new TLine( 0, 0, 1, 1 ) );
   Array.Add( new TLine( 0, 0, 1, 1 ) );

   TLine* Line;
   Int_t i=0;

   Array.Print();

   TIter Next( &Array );

   while( (Line = (TLine*) Next()) ) {
     cout << Line->GetLineColor() << endl;
   }

   Array.Print();

}

The output is, as expected, the content of the list, then three times 1 
(the line color) and, again, the output of the list.

Now I want to apply this scheme to a list containing different objects 
which all inherit from the TAttLine class:

void TAttLineTest()
{
   TObjArray Array;

   Array.Add( new TH1I( "foo", "bar", 0, 0, 0 ) );
   Array.Add( new TLine( 0, 0, 1, 1 ) );
   Array.Add( new TGraph(1) );

   TAttLine* AttLine;
   Int_t i=0;

   Array.Print();

   TIter Next( &Array );
	
   while( (AttLine = (TAttLine*) Next()) ) {
     cout << AttLine->GetLineColor() << endl;
   }

   Array.Print();

}

The script is analog to the example above, but now I use a TAttLine 
pointer to access the objects in the array. Running this script leads to 
a segmentation fault with the following output (with ROOT 5.32):

bash-3.2$ root -x -q TAttLineTest.C
   *******************************************
   *                                         *
   *        W E L C O M E  to  R O O T       *
   *                                         *
   *   Version   5.32/00   2 December 2011   *
   *                                         *
   *  You are welcome to visit our Web site  *
   *          http://root.cern.ch            *
   *                                         *
   *******************************************

ROOT 5.32/00 (tags/v5-32-00 <at> 42375, Jan 24 2012, 13:07:59 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0]
Processing TAttLineTest.C...
Collection name='TObjArray', class='TObjArray', size=16
  TH1.Print Name  = foo, Entries= 0, Total sum= 0
  TLine  X1=0.000000 Y1=0.000000 X2=1.000000 Y2=1.000000
  x[0]=0, y[0]=0
0
0
0
Collection name='TObjArray', class='TObjArray', size=16

  *** Break *** segmentation violation

[...]

===========================================================
#10 0x00000032d70bdb65 in __dynamic_cast () from /usr/lib64/libstdc++.so.6
#11 0x00002ab7e684f42e in TCollection::PrintCollectionEntry 
(this=0x171e3200,
     entry=0x17266360, option=0x2ab7e6cd039b "", recurse=0)
     at /sirius/thl/root/core/cont/src/TCollection.cxx:307
#12 0x00002ab7e684efef in TCollection::Print (this=0x171e3200,
     option=0x2ab7e6cd039b "", recurse=1)
     at /sirius/thl/root/core/cont/src/TCollection.cxx:357
#13 0x00002ab7e684df13 in TCollection::Print (this=0x171e3200,
     option=0x2ab7e6cd039b "")
     at /sirius/thl/root/core/cont/src/TCollection.cxx:334
===========================================================

Somehow, accessing the objects via the TAttList pointer corrupts the 
array. Does anyone know why? I also wonder why the color of the TLine 
object in the list is now '0'...

I've tested this script also on ROOT 5.30 and 5.26 with the same result.

Regards, Thomas