Dear G4 users,
I have come across a strange crash trying to use the /geometry/test/run command in MT mode.
From the tests that I have run the crash appears only for at least 2 threads (if I specify only 1 thread I haven’t noticed it) and it seems to happen during the geometry test at the worker threads.
The test runs fine at the master thread.
Additionally, the crash doesn’t happen all the time!
Trying to debug the crash it seems that it comes during the try to delete G4SmartVoxelHeader during the BuildOptimizations called from CloseGeometry in the RecursiveOverlapTest.
I was wondering, does it make sense to run the geometry test also at the worker threads?
Am I doing something wrong or is this a bug?
The Geant4 version that I use is 10.7 patch 3.
As a minimal working example, I attach the source files that have to be overwritten at the B1 basic example along with the modified input macro.
B1DetectorConstruction.cc (6.3 KB)
B1PrimaryGeneratorAction.cc (4.2 KB)
exampleB1.in.txt (270 Bytes)
Thanks in advance!
1 Like
Dear psaxioti,
I tried your source files with Geant4.11.0 version, and I got segmentation error even 1 thread worked.
I didn’t try yet, but why don’t you try creating different logical volumes per layer rather than repeat creating and placing each layer to one logical volume. <— I tried but there’s also segmentation error…
Best regards,
Jaeyoung Jeong
Dear Jaeyoung Jeong,
thanks for your reply.
The code I posted is just an example to demonstrate the behavior. In my actual code the geometry is controlled by a messenger and the number of volumes and their properties is variable.
Of course I could create some vectors and fill them with the different solids/logical/physical volumes… But I don’t think this is the problem.
I will create a similar example for geant4 version 11.0, with vectors for the volumes and try to see what happens.
My guess is that it is a data race between threads.
I don’t know if it makes sense to check the geometry also at the different threads (to my understanding it is shared with the master), since it is run at the master.
In the case it should be run also at the different threads then I guess it should be MUTEXed???
Best regards,
Axiotis Michail
Dear G4 users,
as a follow up, it seems that the situation is a little bit worse with G4 version 11.0 patch 2.
No need to change anything at the basic B1 example of the distribution.
Just adding the test command in the macro file and you get the crash…, even for 1 tread asked!
The crash appears for Tasking and MT run managers (set by the G4RUN_MANAGER_TYPE environment variable), while for a Serial run manager it runs fine.
Since the crash manifests also for 1 thread asked I no longer think it is a data race…