RE: TClonesArray::Streamer expecting class

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Mon, 15 Aug 2005 11:00:38 -0500


Hi,

There is indeed something odd with the file nuclon.root. How can I regenerate it?

Cheers,
Philippe.

-----Original Message-----
From: Dmitry V.Naumov [mailto:naumov_at_lapp.in2p3.fr] Sent: Monday, August 15, 2005 9:51 AM
To: Philippe Canal
Cc: roottalk_at_cern.ch
Subject: Re: [ROOT] TClonesArray::Streamer expecting class

Hi Philippe,

thank you for your answer and sorry for some delay with my answering (I was out of office).
I tried what you suggested but unfortunatelly it did not help... I copied again the tar ball with my code, all libraries complied with gcc 3.3.5

Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v

--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared 
--enable-__cxa_atexit --with-system-zlib --enable-nls 
--without-included-gettext --enable-clocale=gnu --enable-debug 
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)

and file nuclon.root (I did not include it last time because it can be generated with run_g4.C).
To give you some filling on the problem. If I dump TClonesArray *fDetResponse then I see
that it is always filled with some hits, etc. However reading back the events from the root
file (new root session) I meet "TClonesArray expecting class..." which happenes because
the pointer fDetResponse is not NULL while somewhy it has zero entries...

Thank you in advance, Dmitry

Philippe Canal wrote:

>Hi Dmitry,
>
>I tried and failed to reproduce your problem (It ask for a file
nuclon.root)
>
>However, it sounds like the TTree still sees the address of the deleted
>TClonesArray.
>It would be better if, you function was more like (i.e. keep the existing
>object alive):
>
>void NEvent::SetDetectorResponse(TClonesArray* copy) {
> fDetResponse->Clear();
> for() {
> new ( (*fDetResponse)[i] ) ObjectType( copy->At(i) );
> }
>}
>
>Cheers,
>Philippe.
>
>-----Original Message-----
>From: owner-roottalk_at_pcroot.cern.ch [mailto:owner-roottalk_at_pcroot.cern.ch]
>On Behalf Of Dmitry V.Naumov
>Sent: Wednesday, August 10, 2005 8:48 AM
>To: roottalk_at_cern.ch
>Subject: [ROOT] TClonesArray::Streamer expecting class
>
>Dear rooters,
>
>I have the following problem which I can not figure out myself.
>As the output of VMC+G4 code I save the root file with TTree
>containg NEvent as a branch. The structure of this event is very
>simple:
>
>class NEvent: public TObject {
>public:
><skip>
>private:
>
>NEventHeader *fHeader; // Event header
>TClonesArray *fDetResponse; // -> detector response with hits, etc
>TObjArray *fTracks; // -> tracks
>};
>
>In the code I have the pointer of type NEvent which I fill with needed
>information. For example I use methods like:
>void NEvent::SetDetectorResponse(TClonesArray* copy) {
>fDetResponse = (TClonesArray*)copy->Clone();
><skip>
>}
>
>in order to delete consequently copy from the main body of the code.
>Finally the tree is saved with usual TTree::Fill() method.
>What I get sometimes (and this is what I do not understand) that reading
>back
>the output from the root file reading of some events gives:
>TClonesArray::Streamer expecting class
>
>To be more precise:
>
>Reading 2 event
>Reading 3 event
>Reading 4 event
>TClonesArray::Streamer expecting class 4Ã?}`
>Reading 5 event
>TClonesArray::Streamer expecting class
>Error in <TBuffer::CheckByteCount>: object of class TClonesArray read
>too few bytes: 15 instead of 625760311
>Error in <TBuffer::CheckByteCount>: Byte count probably corrupted around
>buffer position 6807:
>625760311 for a possible maximum of 25174
>
>I was checking in the core of the code that the pointer I pass to my
>NEvent is
>not empty, some slots of TClonesArray are always filled. Doing
>TTree::Print() before
>closing the file looks also OK:
>
>***************************************************************************
*
>**
>
>*Tree :nuclon : nuclon tree *
>*Entries : 6 : Total = 242395 bytes File Size = 74081 *
>* : : Tree compression factor = 2.98 *
>***************************************************************************
*
>**
>
>*Branch :fEvent *
>*Entries : 6 : BranchElement (see below) *
>*..........................................................................
.
>.*
>
>*Br 0 :fUniqueID : *
>*Entries : 6 : Total Size= 682 bytes One basket in memory *
>*Baskets : 0 : Basket Size= 32000 bytes Compression= 1.00 *
>*..........................................................................
.
>.*
>
>*Br 1 :fBits : *
>*Entries : 6 : Total Size= 658 bytes One basket in memory *
>*Baskets : 0 : Basket Size= 32000 bytes Compression= 1.00 *
>*..........................................................................
.
>.*
>
>*Br 2 :fHeader : *
>*Entries : 6 : Total Size= 1400 bytes One basket in memory *
>*Baskets : 0 : Basket Size= 32000 bytes Compression= 1.00 *
>*..........................................................................
.
>.*
>
>*Br 3 :fDetResponse : *
>*Entries : 6 : Total Size= 237055 bytes File Size = 74081 *
>*Baskets : 1 : Basket Size= 32000 bytes Compression= 2.98 *
>*..........................................................................
.
>.*
>
>*Br 4 :fTracks : *
>*Entries : 6 : Total Size= 824 bytes One basket in memory *
>*Baskets : 0 : Basket Size= 32000 bytes Compression= 1.00 *
>*..........................................................................
.
>.*
>
>
>On the root website I found some references for the similar problems
>from which
>I did not figure out the solution or diagnosis like:
>http://root.cern.ch/root/roottalk/roottalk02/4747.html
>
>The tar ball with the code can be found at :
>dnaumov_at_lxplus.cern.ch:~/public/nuc.tar.gz
>The variables are set with source source_me.
>The problem can be reproduced running run_g4.C
>and then
>root[].x EventAnalysis.C
>click "next" 5-6 times to see it.
>
>Thanks in advance, Dmitry
>
>
>
>
>
Received on Mon Aug 15 2005 - 18:02:41 MEST

This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:11 MET