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").