Possible Data Race in electromagnetic examples Cuts

Hello everyone.

I was trying to use TestEm8 as a template for my simulation.
I noticed a lot of “Possible data race” messages using helgrind.
(Most of them were mine to blame, but) the ones which were related to to PhysicsList::SetCuts were not (I think).
The reason for this assessment (that the fault is not mine) is that this particular problem is present with at least some of extended/electromagnetic/ examples when I run them without any changes, just compile and run. I have tried it with

  • TestEm1
  • TestEm4, and
  • TestEm8.

All of the above, when run with 10.7.p1 (tried them also with 10.5) give lots of helgrind errors related to for example

  • G4VUserPhysicsList::SetDefaultCutValue(double) G4VUserPhysicsList.cc:415)

  • SetProductionCut (G4ProductionCuts.hh:152)

  • G4VUserPhysicsList::SetParticleCuts(double, G4String const&, G4Region*) (G4VUserPhysicsList.cc:563)

and

  • the SetCuts function as implemented in the local Physics list, as is the case with TestEM8. An example snippet follows, but there are a lot of similar errors.

Does anyone have any idea why this happens? Should I worry?
Sometimes data races lead to undefined behavior, could this be such a case?
(so far I haven’t noticed any weird stuff, but nonetheless, this is somewhat worrying…)

Thanks a lot!
Dimitris

#####################
this is the product of
$ valgrind --tool=helgrind ./TestEm8 ./TestEm8.in
on g4.10.7 where TestEm8.in is edited for for 8 threads, ie
/run/numberOfThreads 8

[snip]

==570416== Possible data race during write of size 8 at 0x67EDC68 by thread #3
==570416== Locks held: none
==570416== at 0x553722F: G4VRangeToEnergyConverter::SetEnergyRange(double, double) (G4VRangeToEnergyConverter.cc:239)
==570416== by 0x11AF04: PhysicsList::SetCuts() (PhysicsList.cc:248)
==570416== by 0x4F51D2F: G4UserPhysicsListMessenger::SetNewValue(G4UIcommand*, G4String) (G4UserPhysicsListMessenger.cc:268)
==570416== by 0x773DB66: G4UIcommand::DoIt(G4String) (G4UIcommand.cc:262)
==570416== by 0x7733260: G4UIcmdWithADoubleAndUnit::DoIt(G4String) (G4UIcmdWithADoubleAndUnit.cc:89)
==570416== by 0x77534A5: G4UImanager::ApplyCommand(char const*) (G4UImanager.cc:584)
==570416== by 0x4F3D422: G4WorkerRunManager::DoWork() (G4WorkerRunManager.cc:834)
==570416== by 0x4F48364: G4MTRunManagerKernel::StartThread(G4WorkerThread*) (G4MTRunManagerKernel.cc:212)
==570416== by 0x79C8D83: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==570416== by 0x4842B1A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
==570416== by 0x916F608: start_thread (pthread_create.c:477)
==570416== by 0x7D61292: clone (clone.S:95)
==570416==
==570416== This conflicts with a previous write of size 8 by thread #9
==570416== Locks held: none
==570416== at 0x553722F: G4VRangeToEnergyConverter::SetEnergyRange(double, double) (G4VRangeToEnergyConverter.cc:239)
==570416== by 0x11AF04: PhysicsList::SetCuts() (PhysicsList.cc:248)
==570416== by 0x4F51D2F: G4UserPhysicsListMessenger::SetNewValue(G4UIcommand*, G4String) (G4UserPhysicsListMessenger.cc:268)
==570416== by 0x773DB66: G4UIcommand::DoIt(G4String) (G4UIcommand.cc:262)
==570416== by 0x7733260: G4UIcmdWithADoubleAndUnit::DoIt(G4String) (G4UIcmdWithADoubleAndUnit.cc:89)
==570416== by 0x77534A5: G4UImanager::ApplyCommand(char const*) (G4UImanager.cc:584)
==570416== by 0x4F3D422: G4WorkerRunManager::DoWork() (G4WorkerRunManager.cc:834)
==570416== by 0x4F48364: G4MTRunManagerKernel::StartThread(G4WorkerThread*) (G4MTRunManagerKernel.cc:212)
==570416== Address 0x67edc68 is 0 bytes inside data symbol "_ZN25G4VRangeToEnergyConverter12LowestEnergyE"
==570416==
==570416== ----------------------------------------------------------------

[snip]

Hello,

thank you for this post. Can you , please, confirm, that the problem exist/not exist for the Option4 or default EM physics constructor? Can you, please, make Bugzilla bug report?

VI

Hello again.

As far as helgrind’s messages are concerned, the output of
$ valgrind --tool=helgrind ./TestEm8 ./TestEm8.in
is identical in the 2 following cases in TestEm8.in:
/testem/phys/addPhysics emstandard_opt4
and
/testem/phys/addPhysics emstandard_opt0

I also receive the same “possible data race” message if I change to opt4 in the PhysicsList ctor
fEmName = G4String("eG4EmStandard_opt4");
fEmPhysicsList = new G4EmStandardPhysics_option4(0);.
and recompile.

Is this is what you meant by ‘Option4 or default EM physics constructor’?

Dimitris

Hello Dimitris,

thank you very much for the report. When I try this out for the current master of Geant4 I see few problems in recently introduced code but not in G4VRangeToEnergyConverter. In any case, we will try to understand the issue.

VI