I’m using Geant4 in MacOS and got the following error message:
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<P15G4HadFinalState>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<P15G4HadFinalState>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<P15G4HadFinalState>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<P15G4HadFinalState>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
1: Non-critical error: mutex lock failure in ~G4Cache<P15G4HadFinalState>.
1: If the RunManagerKernel has been deleted, it failed to delete an allocated resource
1: and this destructor is being called after the statics were destroyed.
1: Exception: [code: system:22] caught: mutex lock failed: Invalid argument
However, when I run exactly the same code in a linux system, I don’t have such the error.
Version info
Geant4 Version: 11.2.1 C++ standard : C++23
MacOS: 14.4.1 Apple clang: 15.0.0 CMake Version in MacOS: 3.29.3
Linux OS: RHEL 8.9 gcc: 13.1 CMake Version in Linux: 3.28.1
I managed to reproduce the errors from one of Geant4 examples. The cause of the error is the physics list “Shielding” in the MT mode.
Reproduction steps:
Go to the example B2a
Change to MT mode (line 63):
auto runManager =
G4RunManagerFactory::CreateRunManager(G4RunManagerType::MT);
Use the physics “shielding” (line 70):
auto physListFactory = G4PhysListFactory{};
G4VUserPhysicsList* physicsList = physListFactory.GetReferencePhysList("Shielding");
runManager->SetUserInitialization(physicsList);
Compile and run with:
./exampleB2a run2.mac
And you have the following error messages:
Non-critical error: mutex lock failure in ~G4Cache<N26G4ParticleHPContAngularPar10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N26G4ParticleHPContAngularPar10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N26G4ParticleHPContAngularPar10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N26G4ParticleHPContAngularPar10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N26G4ParticleHPContAngularPar10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<P26G4ParticleHPContAngularPar>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N26G4VParticleHPEnergyAngular10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N19G4ParticleHPProduct10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
Non-critical error: mutex lock failure in ~G4Cache<P15G4HadFinalState>.
If the RunManagerKernel has been deleted, it failed to delete an allocated resource
and this destructor is being called after the statics were destroyed.
Exception: [code: system:22] caught: mutex lock failed: Invalid argument
I digged a little bit deeper into the source file that generates these message. It’s the file “G4Cache.hh” at line 293~302. The error message will occur if the derived classes from G4HadFinalState are deleted manually by the Geant4. However, G4Cache requires those objects to be deleted before the static mutex object. Thus, this leads to a undefined behaviour as the system may delete the objects earlier or later than the static mutex object.
So I guess some memory leaking should be fixed on the “Shielding” physics list.
Thank you for reporting this issue. I confirm it. The ParticleHP code seems not to be properly updated when we moved to version 11.0. We will fix it in our next patch release. Meanwhile, if you have no particular reason to stick to the original MT mode, please use task-based parallel mode, i.e.
auto runManager =
G4RunManagerFactory::CreateRunManager(G4RunManagerType::Default);
I didn’t know Geant4 provides task based concurrency from the first glance of the recent Geant4 manuals. Just being curious, if I choose the default option (a.k.a Tasking), which framework am I using for the task management? Executor or sender/receiver? Does that change when I use the TBB option?