Here my thoughts about segfaults that occasionally occur at the end of a simulation.
Scenario: You set up a simulation, run it, get the results just fine, but you get a segmentation fault when the script terminates.
In my opinion, this is caused by the interplay between the G4RunManager and references in python.
More specifically:
In a Geant4 application, the user creates the run manager instance at the beginning, registers all the construction classes (geometry, physics, etc) and then runs Initialize. This constructs the relevant G4 objects (volumes, processes, particles, regions, etc.). At the end of the Geant4 application, the user should explicitly delete the RunManager, i.e. call its destructor. This in turn iterates recursively over all constructors and calls their destructors, this deleting objects and setting pointer to nullptr.
Now, in opengate, i.e. in python, we do not explicitly call the RunManager's destructor. This happens when python garbage collects it. In fact, the pybind code specifies "nodelete" for the pointers to objects which are deleted by the RunManager to ensure that python does not delete them. On the other hand, many python objects in opengate hold references to G4Objects, such as logical volumes, physics list etc. I think, the segfaults occur when the RunManager happens to be garbage collected while such objects with g4 reference are still alive because these reference point to obsolete addresses after the RunManager's destructor.
While it is difficult to explicitly trigger garbage collection and inspect the problem (NB: del XXX does NOT necessarily causes garbage collection, but only removes a reference), one can do the following to understand the problem:
def simulate():
sim = gate.Simulation()
se = gate.SimulationEngine(sim)
DO STUFF
provoke_segfault = False
# if the RunManager is deleted early, it will cause a segfault
if provoke_segfault is True:
del se.g4_RunManager
return None
# If a reference is kept outside of the scope of this function
# all other simulation related objects will be garbage collected
# before the RunManager is destroyed at the very end
# --> no segfault
else:
return se.g4_RunManager
if __name__ == "__main__":
rm = simulate()
What's going on:
The SimulationEngine class holds references to other engines and thereby G4 objects. When the object 'se' goes out of scope, i.e. at the end of simulate(), all these objects are likely garbage collected.
By returning a reference to the RunManager, this latter will live on beyond the scope of simulate() and the G4 objects are destroyed when no other python reference exist anymore.
On the other hand, by explicitly deleting the only reference to the RunManager, namely se.g4_RunManager, garbage collection is triggered (at least in CPython, to my knowledge). by the 'se' objects lives on and with it the references to the G4 objects which no longer exist.
It's quite tricky problem, but I think one solution would be a context manager. Roughly:
Every opengate opengate object holding references to G4 objects should implement a method to releases these references. The SimulationEngine should be context-aware, i.e. implement en enter and exit method, so it can be used with an 'with' statement, like "with open(filename) as f: ...'. The exit method should make sure that all release methods are called before existing the context. Then, the Simulation class should implement a "run()" method which does something like this:
def run(self):
with SimulationEngine() as se:
self.output = se.start()
The SimulationEngine objects (and with it all the hierarchical references to other engines) will be garbage collected when the 'with' context exits, but after the release methods are called. The g4 objects are anyhow not needed anymore and neither the simulation engine, because the simulation object now holds the output.
Going further, and assuming that this is a valid approach, I suggest implementing the release mechanism as part of a BaseClass via a metaclass. Specifically, all attributes pointing at G4Object are stored in a dictionary per class and exposed as properties. A method in the based class can then iterate over these attributes and point them to None to release the reference. Additionally, derived classes can implement their own release method and take care of non-trivial structures holding references to G4 objects.
So far my thoughts. In any case, we need some systematic approach to this RunManager / reference problem. Otherwise, we will always be plagued by segfaults (I fear).
![pre-commit-ci[bot] avatar](https://avatars.githubusercontent.com/in/68672?v=4 "pre-commit-ci[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent