| Summary: | G4PhysicalVolumeMassScene segfaults when computing mass of parallel-world volume | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Michael Kelsey <kelsey> |
| Component: | visualization/modeling | Assignee: | John.Allison |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | ||
| Priority: | P4 | ||
| Version: | 10.4 | ||
| Hardware: | All | ||
| OS: | All | ||
Thanks, Mike. Will fix. Fixed. It was an unprotected pointer to material. It is legitimate for a volume in a parallel world to have no material. Also fixed: printing with /vis/drawTree with verbosity < 10 (notifies but does not print details of repeated volumes) for parameterised volumes. Tagged: vis-V10-04-02 |
Volumes in a parallel world (for example, scoring volumes) are allowed to have null pointers for their material. In such a case, they will not be used for physics, but tracks can still have fGeomBoundary steps. When using /vis/ASCIITree to get a detailed dump of such a volume, there is a segfault at the "Calculating mass(es)..." stage of the output. Specifically: Process 92000 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x38) frame #0: 0x000000010384e415 libG4modeling.dylib`G4PhysicalVolumeMassScene::ProcessVolume(G4VSolid const&) [inlined] G4Material::GetDensity(this=0x0000000000000000) const at G4Material.hh:180 [opt] 177 // 178 inline const G4String& GetName() const {return fName;} 179 inline const G4String& GetChemicalFormula() const {return fChemicalFormula;} -> 180 inline G4double GetDensity() const {return fDensity;} 181 inline G4State GetState() const {return fState;} 182 inline G4double GetTemperature() const {return fTemp;} 183 inline G4double GetPressure() const {return fPressure;} Target 0: (CDMS_SimDraw) stopped. (lldb) f 1 frame #1: 0x000000010384e415 libG4modeling.dylib`G4PhysicalVolumeMassScene::ProcessVolume(this=0x00007ffeefbfd508, solid=0x0000000108eaa0f0) at G4PhysicalVolumeMassScene.cc:81 [opt] 78 } 79 80 G4double currentVolume = ((G4VSolid&)solid).GetCubicVolume(); -> 81 G4double currentDensity = pCurrentMaterial->GetDensity(); 82 /* Using G4Polyhedron... (gives slightly different answers on Tubs, e.g.). 83 G4Polyhedron* pPolyhedron = solid.GetPolyhedron(); 84 if (!pPolyhedron) { Here, the pCurrentMaterial pointer is (correctly) null, and should not be dereferenced. Perhaps G4PhysicalVolumeMassScene::ProcessVolume() should check that pointer at the start, and assign a zero mass with no other processing? NOTE: This bug has been present since at least Geant4 9.6 (when the function was named "AccrueMass").