reading and writing events leaks memory

[tmadlener]

It is not really visible with the 2000 events that are currently used for the tests, but simply increasing that number and monitoring the memory consumption of the corresponding process shows that it continuously increases with the running time of the process. I am not yet sure where / what memory is leaked, but it is not negligible. For me the memory footprint for tests/write increases from about 120M at startup to 1150M when writing 1e6 events. Similarly, tests/read starts off at around 220M and increases to 1000M at the end.

Repeating the tests with different readers / writers, e.g. the SIOReader and SIOWriter from #130, shows similar behavior, so it seems that the interplay between the readers / writers and the EventStore could be the culprit here.

[tmadlener]

So there are two different "large" memory leaks, depending on whether we are writing or reading. Large in this case means that memory is leaked for every event. Additionally, there are a few "small" leaks, where we leak only once for the whole execution. (There are also a few other leaks from within the depths of ROOT, but those or not really our concern, I suppose).

The small ones:

• m_table in EventStore (see Fix memory leaks in EventStore and Reader/Writer interplay #134 for a fix)
• temporary l_table in ROOTReader::openFiles (see Read the collectionID table directly #135 for a fix)

The large ones:

• When reading we leak all the metadata pointers that are newly allocated by the readers, because, even though the EventStore doesn't really take ownership of the data provided by the reader, but instead copies the data into its members. E.g. here:
  

  podio/src/EventStore.cc

  Lines 89 to 97 in d4a0265

  	GenericParameters& EventStore::getEventMetaData() const {
  	if( m_reader != nullptr ){
  	m_evtMD.clear() ;
  	GenericParameters* tmp = m_reader->readEventMetaData() ;
  	m_evtMD = *tmp ;
  	}
  	return m_evtMD ;
  	}

  
  Moving the data into the internal member and deleting the temporary pointer, fixes this (also fixed in Fix memory leaks in EventStore and Reader/Writer interplay #134)
• When writing the situtation is a bit more complex. Memory is leaked when we create objects with VectorMembers (potentially others too, but definitely with these) outside of collections and then add them to collections via push_back, e.g. in the form of

ExampleWithVectorMemberCollection coll;
auto vec = ExampleWithVectorMember();
coll.push_back(vec)

The problem is that as soon as we push the vec to the collection, it becomes tracked by the collection, and the deconstructor will only delete the internal vector in ExampleWithVectorMemberObj that is allocated via new if it is not tracked. The collection should in principle do this, but does not do it at the moment. Assuming that the object can become invalid as soon as the collection is cleared, then the fix is simply to make the collection properly clean up all its related memory (this is also implemented in #134).