Segmentation fault: No AtRestDoIt process is active!

I have a simple simulation involving protons impinging onto a target composed of water.

When I include Hadron inelastic physics into my PhysicsList the simulation ends abruptly with a Segmentation Fault and the following Warning message:

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : Tracking0013
issued by : G4SteppingManager::InvokeAtRestDoItProcs()
No AtRestDoIt process is active!
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

Segmentation fault (core dumped)

When I turn verbose mode on, this is preceded with the production of a triton.

Here is the longer output which is obtained when the code is executed with valgrind in case it helps anyone:

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : Tracking0013
      issued by : G4SteppingManager::InvokeAtRestDoItProcs()
No AtRestDoIt process is active!
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

==1806877== Invalid read of size 8
==1806877==    at 0x5C139A2: G4SteppingManager::InvokeAtRestDoItProcs() (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4tracking.so)
==1806877==    by 0x5C1073F: G4SteppingManager::Stepping() (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4tracking.so)
==1806877==    by 0x5C1B8EB: G4TrackingManager::ProcessOneTrack(G4Track*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4tracking.so)
==1806877==    by 0x5B85B29: G4EventManager::DoProcessing(G4Event*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4event.so)
==1806877==    by 0x4F0EB56: G4RunManager::DoEventLoop(int, char const*, int) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4run.so)
==1806877==    by 0x4F0C7A1: G4RunManager::BeamOn(int, char const*, int) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4run.so)
==1806877==    by 0x4F29286: G4RunMessenger::SetNewValue(G4UIcommand*, G4String) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4run.so)
==1806877==    by 0x4F8BC42: G4UIcommand::DoIt(G4String) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4FAAAAE: G4UImanager::ApplyCommand(char const*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4F7A570: G4UIbatch::ExecCommand(G4String const&) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4F7C525: G4UIbatch::SessionStart() (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4FAC31F: G4UImanager::ExecuteMacroFile(char const*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1806877== 
==1806877== 
==1806877== Process terminating with default action of signal 11 (SIGSEGV)
==1806877==  Access not within mapped region at address 0x0
==1806877==    at 0x5C139A2: G4SteppingManager::InvokeAtRestDoItProcs() (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4tracking.so)
==1806877==    by 0x5C1073F: G4SteppingManager::Stepping() (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4tracking.so)
==1806877==    by 0x5C1B8EB: G4TrackingManager::ProcessOneTrack(G4Track*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4tracking.so)
==1806877==    by 0x5B85B29: G4EventManager::DoProcessing(G4Event*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4event.so)
==1806877==    by 0x4F0EB56: G4RunManager::DoEventLoop(int, char const*, int) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4run.so)
==1806877==    by 0x4F0C7A1: G4RunManager::BeamOn(int, char const*, int) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4run.so)
==1806877==    by 0x4F29286: G4RunMessenger::SetNewValue(G4UIcommand*, G4String) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4run.so)
==1806877==    by 0x4F8BC42: G4UIcommand::DoIt(G4String) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4FAAAAE: G4UImanager::ApplyCommand(char const*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4F7A570: G4UIbatch::ExecCommand(G4String const&) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4F7C525: G4UIbatch::SessionStart() (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==    by 0x4FAC31F: G4UImanager::ExecuteMacroFile(char const*) (in /usr/local/bin/geant4-10/geant4-v10.6.3-install/lib/libG4intercoms.so)
==1806877==  If you believe this happened as a result of a stack
==1806877==  overflow in your program's main thread (unlikely but
==1806877==  possible), you can try to increase the size of the
==1806877==  main thread stack using the --main-stacksize= flag.
==1806877==  The main thread stack size used in this run was 8388608.
==1806877== 
==1806877== HEAP SUMMARY:
==1806877==     in use at exit: 17,604,693 bytes in 150,993 blocks
==1806877==   total heap usage: 1,240,228 allocs, 1,089,235 frees, 79,934,573 bytes allocated
==1806877== 
==1806877== LEAK SUMMARY:
==1806877==    definitely lost: 568 bytes in 4 blocks
==1806877==    indirectly lost: 64 bytes in 2 blocks
==1806877==      possibly lost: 160 bytes in 2 blocks
==1806877==    still reachable: 17,603,901 bytes in 150,985 blocks
==1806877==                       of which reachable via heuristic:
==1806877==                         newarray           : 8,200 bytes in 5 blocks
==1806877==                         multipleinheritance: 112 bytes in 1 blocks
==1806877==         suppressed: 0 bytes in 0 blocks
==1806877== Rerun with --leak-check=full to see details of leaked memory
==1806877== 
==1806877== For lists of detected and suppressed errors, rerun with: -s
==1806877== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

My question is simple, does anyone know how I can prevent this from happening and allow my simulation to produce results? Any help/advice you can provide would be very appreciated.

I’ll give this a shameless bump back to the top and provide more information: it really appears to be something to do with tritons or long-lived particles, since if I use a triton primary the Seg Fault appears immediately following the first triton coming to rest.

Could this be related to the maximum lifetime of particles in G4RadioactiveDecayPhysics? It is currently set to 1.4427e+06 ps and I’m not sure how to change this value?