TTree::Scan of TCloneArray with embedded array, if empty

Dear ROOTers,

I’m saving in a TTree an object like:

class DataArray : public TObject
   int nch;
   int *ch; //[nch]

   // ..etc..

(You can find the full code in the attached tgz… it is a bit messy sorry… it is still under construction…)

And I save also a TCloneArray of such DataArrays.
The problem is that sometimes I get a crash when Scan()ning the TTree, asking for the variable size embedded array, i.e. asking ’ tree.Scan(“”) ’
I discovered that the crash is triggered by an empty TCloneArray in the first scanned entry.

I have prepared in the attached tgz the script “test2.C” producing a tree with 3 entries, the first and the last ones are empty.
I tested:

  1. tree.Scan(“”,"","",100,0)
  2. tree.Scan(“”,"","",100,1)
  3. tree.Scan(“”,"","",100,2)

I get crash in the first and third case, while the second one works as expected (showing also the third empty entry without problem).

Am I wrong in the way I write such object in the TTree?
In fact, to be honest, the space for the variable size array is allocated only once during object construction (you can use a large number) and the same space is reused every time, to avoid the cost of memory reallocation during tree filling: in the full code you can see the int “nallocated” used to know the allocated space; the default constructor do not allocate anything (it is there for the I/O).
I checked the auto-generated streamer by rootcint and it seems fine: it takes “nch” as array length and not “nallocated”.

To make a summary, this code seems to works fine if directly embedded in the tree, but gives this problem if contained in a TCloneArray.
I believe that asking for “all the elements of a variables size array of an object, for all the objects contained in a TCloneArray” is supported, because if I found a similar case in the “Event” ROOT example and if I Draw() the same request I do not get any crash.

I would be very grateful if you can help me with some explanation.

Thanks a lot,
DataArraytest.tgz (3.1 KB)


Thanks for reporting this problem. It is fixed by revision 34590 of the trunk.


PS. Note that to avoid memory leak you ought to use the destructor: virtual ~DataArray() { if(ch) delete [] ch; };(note the extra brackets)