"Mutex lock failure" at end-of-job with RunManagerMT on MacOS

Particles, Track, Event, Run and Biasing
1

Geant4 Version: 11.4.0
Operating System: MacOS Tahoe 26.2
Compiler/Version: Apple Clang 17.0.0
CMake Version: 4.2.1

This is a duplicate of existing forum topics (and others), just bumping it for 11.4.0.

It seems that the necessary fixes for ParticleHP weren’t completed for 11.4.0.

Running a simulation job using the *Shielding_EMZ" physics list, my log file goes from 42 kB during the run to 26 MB at the end of run, with 81,902 copies of the same “mutex lock failure” message:

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: generic:22] caught: mutex lock failed: Invalid argument

These messages are distributed among eight different G4Cache instances:

~G4Cache<N19G4ParticleHPAngular10toBeCachedE>.
~G4Cache<N19G4ParticleHPProduct10toBeCachedE>.
~G4Cache<N26G4ParticleHPContAngularPar10toBeCachedE>.
~G4Cache<N26G4VParticleHPEnergyAngular10toBeCachedE>.
~G4Cache<N28G4ParticleHPEnAngCorrelation10toBeCachedE>.
~G4Cache<P15G4HadFinalState>.
~G4Cache<P26G4ParticleHPContAngularPar>.
~G4Cache<PNSt3__16vectorIiNS_9allocatorIiEEEE>.

Is there any estimate on when this might be resolved? Since there’s absolutely nothing an application developer can do about it, maybe the message itself could be suppressed behind a #ifdef G4VERBOSE protection?

1 Like
2

For what it is worth, this issue is also still relevant for us, and we have for now stuck with Geant4 11.1.x while crossing our fingers it will get resolved at some point before we are forced to upgrade for some other reason.

3

I did not find that anyone had created a Bugzilla report about this issue (mine is the fourth independent forum posting about it), so I have created one: 2696 – Thousands of "Non-critical" mutex lock failure from G4Cache at end of job. This appears to happen only on MacOS, but with both Intel and Apple Silicon chips.

I noted in that ticket that our simulation framework instantiates the G4RunManagerMT on the stack, rather than going through the RM factory:

    G4RunManagerMT runManager;

which means that it gets deleted implicitly when main() goes out of scope. Is this (a) no longer a valid approach, or (b) something that LLVM has trouble with when there are global statics?