Skip to content

The Rise of the Persistent Clipboard Storage

Simon Spannagel requested to merge fix_trackcopy into master

This MR fixes any problems with copying track objects (memory leaks, missing references, ...) - simply by disallowing it. Now, let me explain a bit more in detail:

Attack of the Track->Clone()s

Some modules need to retain objects longer than the current event, such as the alignment modules which keep tracks for running the actual residual minimization at the end of the run. Up till now, they locally copied a new object from the existing track. Since they access cluster information during the minimization, there was a very crude copy-constructor for tracks which would create local copies (new Cluster()) of the associated clusters and thereby opening a huge memory leak - because they were never cleaned up.

A New Hope

Now, the right way with smart pointers (which we have since !305 (merged) in) is to simply keep a copy of the smart pointer - and automatically the object will not be deallocated at the end of the event. In order to ease this process, I have revamped the "persistent storage element" of the clipboard for this. Up till now, this was completely unused and not really useful as it was just a remainder of some workaround structure we needed before properly introducing the Event class.

Now, the clipboard persistent storage

  • is able to store anything than can be placed on the event storage
  • can accumulate data over many events
  • can provide this data in the finalize function via a read-only instance of the clipboard

Placing things on that clipboard storage works (almost) like the other storage:

  • select e.g. tracks you want to add, collect them in a vector
  • call putPersistentData() to add them, possibly with a detector key attached.

Revenge of the Shared Pointers

Now one thing we still need to take care of is the related objects. I do not want to add automatic magic to crawl the history of an object and also add all of these objects automatically, but I would like ot rely on the developer to copy all relevant objects to the persistent storage. This means:

For the AlignmentDUTResidual module, we only need tracks and its associated clusters. This means, I call putPersistentData(tracks) to store the relevant tracks and then need to get their associated clusters and also add them. Since track->getAssociatedClusters() returns a vector of raw pointers (due to TRef storage) this is not straight forward. Therefore, the clipboard has an additional helper function called copyPesistentData() which takes these raw pointers, looks up the proper data on the event storage and copies the shared pointer over to persistent storage for later reference.

For AlignmentTrackChi2, we don't need the associated clusters, but the track clusters, so we do the same game with track->getClusters() and live happily ever after.

The Last Feedback

I would like to get some feedback on the user interface, especially look at the changes required for the alignment modules and whether you find this intuitive or not.

Edited by Simon Spannagel

Merge request reports