Memory leak when loading events from .ghep file about generator HOT 5 OPEN

Digging a little further, it seems that the problem is likely that ROOT isn't actually calling NtpMCEventRecord::~NtpMCEventRecord() when it loads a new entry from the file, but simply writing over it (which does call the constructor for the new entry, and that involves a new EventRecord inside NtpMCEventRecord::Init()).

from generator.

I believe this issue showed up with the switch to ROOT 6. There was an issue open in the old trac system about it but that system seems not to have survived the move away from hepforge.

Assuming it's the same thing, the way I mostly reproduced it was just running a TTree::Draw on the GHEP file.

from generator.

... and reading a bit further, it looks like we're violating the serialization rules from ROOT (https://root.cern.ch/root/html/guides/users-guide/AddingaClass.html#the-default-constructor):

Be sure that you do not allocate any space for embedded pointer objects in this constructor. This space will be lost (memory leak) while reading in the object. For example:

class T49Event : public TObject {
private:
Int_t        fId;
TCollection *fTracks;
...
public:
   // Error space for TList pointer will be lost
T49Event() { fId = 0; fTrack = new TList; }
   // Correct default initialization of pointer
T49Event() { fId = 0; fTrack = 0; }
...
};

The memory will be lost because during reading of the object the pointer will be set to the object it was pointing to at the time the object was written. Create the fTrack list when you need it, e.g. when you start filling the list or in a not-default constructor.

We are doing the new EventRecord in the default constructor.

from generator.

This serialisation rule was a problem in many contexts before and it was solved by leaving the default ctor as is (if it allocates memory so be it) but adding a new ctor only for ROOT I/O purposes. This is done, for example, in GHepRecord::GHepRecord(TRootIOCtor*).
Not sure what changed with ROOT6 wrt NtpMCEventRecord.

from generator.

Ah, I didn't know that such a construction existed. There's no analogous constructor for NtpMCEventRecord, so maybe just adding one would do the trick?

I don't have a 3.00.06-equivalent version of GENIE currently built from source in an area I can modify so I can't test quickly, but maybe somebody can? (If not I can look into it but won't be able to get to it right away)

from generator.