Re: Strange TClonesArray problem

Hi,

an error message plus a subsequent crash is optimal. It's hard to guess (or agree on) what the desired outcome of writing the tree would be otherwise.

Cheers, Axel.

Filimon Roukoutakis wrote on 01/19/2011 03:26 PM:
> Hi Axel, thanks this debugging procedure pointed me to discover the
> problem, there was a missing namespace in fact it is MyNS::MyClass and
> not MyClass. I guess one cannot expect name lookup to work in this
> context, right? :-) I can use MyClass without MyNS everywhere inside
> this piece of code.
> Now it seems to work (I would like to start filling the TClonesArray
> with the actual data to be sure but at least it does not crash)
> There is the issue of why getting a crash in the first place? Couldn't
> there be a away to stop gracefully? I guess a check for nullptr in a
> TClass::GetClass is missing somewhere in
>
> TClass::GetStreamerInfo(int)?
>
> In fact one gets a message "Error in<TClonesArray::SetClass>: called
> with a null pointer" (lost in the output of one's application... I was
> just wondering whether this info could be used in the GetStreamerInfo.
>
> Thanks,
> filimon
>
> On 01/19/2011 02:32 PM, Axel Naumann wrote:

>> Hi,
>>
>> can you call
>>
>> gROOT->ProcessLine(".class MyClass")
>> if (TClass::GetClass("MyClass")) TClass::GetClass("MyClass")->Dump()
>> else printf("No TClass for MyClass!\n");
>>
>> before writing out the tree? What's the output?
>>
>> Cheers, Axel.
>>
>> Filimon Roukoutakis wrote on 01/19/2011 02:22 PM:
>>> Hi, I get a strange problem related to TClonesArray. When initiliazing
>>> on a MyEvent class ctor a member fMyArray with new
>>> TClonesArray("TParticle", 100000), even TClonesArray("TClonesArray",
>>> 10000000)!) everything works like a charm. But when doing new
>>> TClonesArray("MyClass", 100000) I get the wonderful output below, when
>>> eventually trying to write MyEvent in a TTree. MyClass inherits from
>>> TObject, has ClassDef and an appropriate entry in my linkdef.h #pragma
>>> link C++ class MyClass+; Is is more simple than a TParticle (5 Int_t, 10
>>> Double_t, no mult inheritance, no allocation, no pointers, just a POD
>>> 5*32+10*64+TObject). What could be the problem (ie is there any
>>> additional requirement for MyClass)? The problem persists even if I use
>>> the default second argument for TClonesArray (I believe it is 100).
>>> Thanks,
>>> filimon
>>>
>>> *** Break *** segmentation violation
>>> .......
>>> .......
>>>
>>> ===========================================================
>>> #10 0x00900e94 in TClass::GetStreamerInfo(int) const () from
>>> /opt/root/v5-28-00/lib/libCore.so.5.28
>>> #11 0x06e82b03 in TBufferFile::ForceWriteInfoClones(TClonesArray*) ()
>>> from /opt/root/v5-28-00/lib/libRIO.so
>>> #12 0x008dbabf in TClonesArray::Streamer(TBuffer&) () from
>>> /opt/root/v5-28-00/lib/libCore.so.5.28
>>> #13 0x008feb84 in TClass::StreamerTObjectInitialized(void*, TBuffer&,
>>> TClass const*) const () from /opt/root/v5-28-00/lib/libCore.so.5.28
>>> #14 0x06e880b7 in TBufferFile::WriteObjectClass(void const*, TClass
>>> const*) () from /opt/root/v5-28-00/lib/libRIO.so
>>> #15 0x06e84eba in TBufferFile::WriteObjectAny(void const*, TClass
>>> const*) () from /opt/root/v5-28-00/lib/libRIO.so
>>> #16 0x06e87727 in TBufferFile::WriteFastArray(void**, TClass const*,
>>> int, bool, TMemberStreamer*) () from /opt/root/v5-28-00/lib/libRIO.so
>>> #17 0x06f530a3 in int TStreamerInfo::WriteBufferAux<char**>(TBuffer&,
>>> char** const&, int, int, int, int) () from
>>> /opt/root/v5-28-00/lib/libRIO.so
>>> #18 0x0182b9ce in TBranchElement::FillLeaves(TBuffer&) () from
>>> /opt/root/v5-28-00/lib/libTree.so
>>> #19 0x01821720 in TBranch::Fill() () from
>>> /opt/root/v5-28-00/lib/libTree.so
>>> #20 0x01827f10 in TBranchElement::Fill() () from
>>> /opt/root/v5-28-00/lib/libTree.so
>>> #21 0x01827ee8 in TBranchElement::Fill() () from
>>> /opt/root/v5-28-00/lib/libTree.so
>>> #22 0x01872aff in TTree::Fill() () from
>>> /opt/root/v5-28-00/lib/libTree.so
>>>