TL;DR Is there any specific guidance on how to migrate user-side G4VTouchable subclasses from G4 v10 to G4 v11?
The CDMS experiment is finally migrating our simulation framework from G4 10.07.p04 to G4 v11 (11.3.2, soon 11.4.0). We are getting systematic segfaults from allocating or deallocating G4TouchableHistory objects, both from our own code as well as from with G4 tracking.
I believe I’ve narrowed the problem down to our internal CDMSTouchable class, which inherits directly from G4VTouchable (no longer a class), and which does not have an associated G4Allocator. In G4 v10, this inheritance was not a problem, but in G4 v11, G4VTouchable is now an alias for G4TouchableHistory, which uses G4Allocator for memory management.
As warned in Global Usage Classes — Geant4 Documentation 11.3 documentation, “classes which are handled by G4Allocator should avoid to be used as base-classes for others.” Is it sufficient for us to define an Allocator for our CDMSTouchable class? Or are there other things we need to do to make this class compatible with Geant4 v11?
In particular, is there any concrete, specific documentation available for “migrating Touchable classes from Geant4 v10 to v11”?
We had not seen any external implementation of G4VTouchable - which is the reason we proceeded this consolidation.
Could you give us some context about the use of the custom CDMSTouchable class?
If it aggregates other abilities, beyond those of G4TouchableHistory, it could own or reference an object of G4TouchableHistory.
If it is a lightweight object with similar capabilities, does it need to be used interchangeably (with G4Touchable), or could it live as a separate type (with the same interface)?
We are using it (in a Geant4 v10 context) as a “downcast” of G4 touchables, with the addition of pre-computing the net global and local rotation matrices and positions. We discard the “history depth” information because we don’t need it.
The main place we use it is with our sources and geometry builders, to allow user specification of coordinates and directions either relative to a specific object, or in global coordinates. We have a CDMSGeometryTools factory class, inspired by Pedro’s GmGeometryUtils from GAMOS, which is where we create these objects (among many other things).
I don’t think we have anywhere that we pass a CDMSTouchable* back into Geant4 code, expecting it to be cast up to G4VTouchable*. If I’m right about that, then we could replace the inheritance with a simple class that “just happens” to have the same member functions.
What I thought was proper OOD with the old G4VTouchable is that it defines a specific interface, which all of its subclasses are required to follow. It doesn’t have any data members, just virtual functions. That’s pretty much what we were using it for.
@japost Your suggestion worked for us. I removed the inheritance of CDMSTouchable from G4VTouchable, and in the constructor that takes a G4VTouchable as input, I stash the const pointer in a data member, with a public accessor. There were two places in the CDMS code where a CDMSTouchable* was being passed to external functions that expected a G4VTouchable* argument. I added the new accessor in those two places.
Our code compiles, links, and produces identical results in the test jobs I ran. No segfaults, and no complaints from Valgrind. Thank you for the help!