RE: i/o of objects with multiple references

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Mon, 30 Jan 2006 13:34:49 -0600

Hi Sue,

I can reproduce the problem and I am looking for the right solution.

Cheers,
Philippe

-----Original Message-----

From: owner-roottalk_at_pcroot.cern.ch [mailto:owner-roottalk_at_pcroot.cern.ch] On Behalf Of Sue Kasahara
Sent: Sunday, January 29, 2006 4:03 PM
To: roottalk_at_pcroot.cern.ch
Subject: [ROOT] i/o of objects with multiple references

Hi roottalk,
I have an example of a data structure that doesn't behave the way I would expect it to behave on i/o, and I'm wondering if you can help me understand what should be done. One of our record types has an odd structure due to historical reasons, so I apologize in advance for what I'm about to show you. A simplified version of this record (SimRecord) is in the tar file, and it has:
  A TObjArray containing:

     i)a TClonesArray of Hit's.
    ii)a Signal object which has a std::map<const Hit*, Float_t weight>

       data member containing a list of Hit ptrs which are a subset of those
       contained in the TClonesArray.

The Signal does not have ownership of the Hit's, which are all owned by the TClonesArray.
The entire TObjArray is written out to one branch of a root TTree. I find that on input, the range of Hit ptr addresses in the Signal map do not match those stored in the TClonesArray, indicating that multiple referencing to individual Hit objects were not reconstructed properly on input. This causes
a memory leak on input.
  This is not the behavior that I would expect given that both the TClonesArray
and Signal object were written out to the same TObjArray data branch.   Is there a reason for this, and is there a way to properly input the data while
avoiding a memory leak, given that we already have a large number of files with
data stored in this format?
The tar file contains a script testwrt.C to create a small data file, and testrd.C
to read the file, to illustrate the problem. I am using root development, dated Jan. 22, 2006, on linux. Thanks for your help in advance.
Regards,
-Sue
Received on Mon Jan 30 2006 - 20:47:14 MET