Segmentation fault during writing FairGeoParset with FairRunAna

[YanzhaoW]

Describe the bug

Running the FairRunAna task with an input parameter file containing any ParSet (such as FairGeoParSet) leads to Segmentation fault in the end of the program.

Cause

delete keyword and no ownership

Further explanation

When running the simulation, FairRunSim automatically put FairGeoParSet into the output parameter file. When using the output file as the input file for FairRunAna, it automatically load the parameter and put it into the container list, which will be eventually written to another output parameter file, including all this member variables:

https://github.com/FairRootGroup/FairRoot/blob/99be5f48d4bfed7ee7179524c07bc49a6b37a5c5/fairroot/base/sim/FairGeoParSet.h#L72-L79

From here, you could see the TGeoManager will also be written to the file.

So when and where will the parameters be written to the output file? The answer is in the destructor of FairRun when it tries to delete FairRuntimeDb.

https://github.com/FairRootGroup/FairRoot/blob/99be5f48d4bfed7ee7179524c07bc49a6b37a5c5/fairroot/base/steer/FairRun.cxx#L81-L104

But before it comes to this, the destructor of FairRunAna must also be called. And what its destructor does is:

https://github.com/FairRootGroup/FairRoot/blob/99be5f48d4bfed7ee7179524c07bc49a6b37a5c5/fairroot/base/steer/FairRunAna.cxx#L93-L108

So it deletes the TGeoManager object and all its volumes. But at the same time, FairGeoParSet also have a reference to this TGeoManager, which is ready to be written to the parameter file. When the writing occurs, TGeoManager already got deleted and BOOM we have segmentation fault!

Temporary solution

Remove everything in FairRunAna destructor. Or write all parameters before calling FairRunAna destructor:

run->GetRuntimeDb()->writeContainers();

(several hours down to the drain :( )

[fuhlig1]

@YanzhaoW,

thanks for the report. Do you have a short demonstrator to reproduce the problem? Currently I am wondering why the problem wasn't seen before.

[YanzhaoW]

@fuhlig1

Hi, sorry that I don't have a "short" example to reproduce the problem. The problem occurs when I use R3BRoot and later I found it's due to the memory mismanagement from FairRoot.

Currently I am wondering why the problem wasn't seen before.

Use after deletion is always an undefined behaviour, which doesn't guarantee its occurrence. Also following situations can also hide this bug:

• The destructor of FairRunAna is not called. This can happen if someone initialises it with new operator and forgets to delete it in the end.
• Parameters are saved before calling the destructor of FairRun.

Is there any existing test that could potentially be used for this detecting this bug?