In the PostStepDoIt of a G4OpBoundaryProcess there is a conditional that manages the processing when the step length is lower than the defined fCarTolerance: https://github.com/Geant4/geant4/blob/84f33a068c5e0acb278dc4e4acb6a2822c6e7bca/source/processes/optical/src/G4OpBoundaryProcess.cc#L186 If the condition is fulfilled, the group velocity of the optical photons on the second (post) material is requested: G4MaterialPropertyVector* groupvel = fMaterial2->GetMaterialPropertiesTable()->GetProperty(kGROUPVEL); This assumes that the fMaterial2 has a G4MaterialPropertiesTable: if the table is not defined, fMaterial2->GetMaterialPropertiesTable() will return a nullptr causing a segmentation fault after the ->GetProperty(kGROUPVEL) call.
Hello, I would like to comment that I do observe the same problem using v11.0.p2. Following the hints in this bug report, I narrowed it down to the transition: Photon at Boundary! thePrePV: ConeRadiator RICH_Ne thePostPV: MylarCone G4_MYLAR for the optical photon. So it happens when going from neon in the RICH with optical properites to the post step volume with mylar material, for which no optical parameters are defined, i.e. no properties are added. The crash appears indeed at the request for the group velocity from G4MaterialPropertiesTable inside the G4OpBoundaryProcess::PostStepDoIt. Maybe this comment can help for debugging. Thanks for more feedback or a solution/fix. Best regards.
Thanks both for reporting this. It is now fixed for version 11.1 and 11.0.2. In addition to the line identified by @Gonzalo, the same fault occurs later in PostStepDoIt(): https://geant4.kek.jp/lxr/source/processes/optical/src/G4OpBoundaryProcess.cc?v=11.0#L505 and has also been fixed.
