Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Thread-safety #28

Closed
gipert opened this issue Oct 1, 2022 · 2 comments
Closed

Thread-safety #28

gipert opened this issue Oct 1, 2022 · 2 comments

Comments

@gipert
Copy link

gipert commented Oct 1, 2022

I was wondering whether BxDecay0 is thread-safe. I have tried embedding it in my GEANT4 application (by using the built-in extension) and it works fine in sequential mode, but segfaults in multi-threaded mode. The stack trace is never the same (symptom of some non-deterministic race condition), but seems to point to a problem in libBxDeca0.so. For example:

malloc(): unaligned tcache chunk detected

### CAUGHT SIGNAL: 6 ### address: 0x3e800008cf8,  signal =  SIGABRT, value =    6, description = abort program (formerly SIGIOT). 

Backtrace:
[PID=36088, TID=4][ 0/27]> /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c) [0x7f8ea6696a7c]
[PID=36088, TID=4][ 1/27]> /lib/x86_64-linux-gnu/libc.so.6(raise+0x16) [0x7f8ea6642476]
[PID=36088, TID=4][ 2/27]> /lib/x86_64-linux-gnu/libc.so.6(abort+0xd3) [0x7f8ea66287f3]
[PID=36088, TID=4][ 3/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x896f6) [0x7f8ea66896f6]
[PID=36088, TID=4][ 4/27]> /lib/x86_64-linux-gnu/libc.so.6(+0xa0d7c) [0x7f8ea66a0d7c]
[PID=36088, TID=4][ 5/27]> /lib/x86_64-linux-gnu/libc.so.6(+0xa545c) [0x7f8ea66a545c]
[PID=36088, TID=4][ 6/27]> /lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1c) [0x7f8ea6aaea0c]
[PID=36088, TID=4][ 7/27]> /opt/bxdecay0/lib/libBxDecay0.so(+0x1d41d) [0x7f8ea117241d]
[PID=36088, TID=4][ 8/27]> /opt/bxdecay0/lib/libBxDecay0.so(+0x1d535) [0x7f8ea1172535]
[PID=36088, TID=4][ 9/27]> /opt/bxdecay0/lib/libBxDecay0.so(_ZN8bxdecay012get_resourceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb+0x48) [0x7f8ea1172b48]
[PID=36088, TID=4][10/27]> /opt/bxdecay0/lib/libBxDecay0.so(_ZN8bxdecay012dbd_isotopesB5cxx11Ev+0x13f) [0x7f8ea118533f]
[PID=36088, TID=4][11/27]> /opt/bxdecay0/lib/libBxDecay0_Geant4.so(_ZN11bxdecay0_g422PrimaryGeneratorAction18ApplyConfigurationEv+0x19e) [0x7f8ea6c6ea1e]
[PID=36088, TID=4][12/27]> /opt/bxdecay0/lib/libBxDecay0_Geant4.so(_ZN11bxdecay0_g422PrimaryGeneratorAction10pimpl_type10get_decay0Ev+0xc0) [0x7f8ea6c6f070]
[PID=36088, TID=4][13/27]> /opt/bxdecay0/lib/libBxDecay0_Geant4.so(_ZN11bxdecay0_g422PrimaryGeneratorAction17GeneratePrimariesEP7G4Event+0xb0) [0x7f8ea6c6f6e0]
[PID=36088, TID=4][14/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager13GenerateEventEi+0x1a1) [0x7f8ea61c89d1]
[PID=36088, TID=4][15/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager15ProcessOneEventEi+0x14) [0x7f8ea61c68a4]
[PID=36088, TID=4][16/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager11DoEventLoopEiPKci+0x176) [0x7f8ea61c65d6]
[PID=36088, TID=4][17/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager6DoWorkEv+0x126) [0x7f8ea61c6786]
[PID=36088, TID=4][18/27]> /opt/geant4/lib/libG4tasking.so(+0x3c542) [0x7f8ea61b8542]
[PID=36088, TID=4][19/27]> /opt/geant4/lib/libG4tasking.so(_ZNSt13__future_base13_State_baseV29_M_do_setEPSt8functionIFSt10unique_ptrINS_12_Result_baseENS3_8_DeleterEEvEEPb+0x2d) [0x7f8ea61bca4d]
[PID=36088, TID=4][20/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x99f68) [0x7f8ea6699f68]
[PID=36088, TID=4][21/27]> /opt/geant4/lib/libG4tasking.so(_ZN3PTL4TaskIvJEEclEv+0x107) [0x7f8ea61bcba7]
[PID=36088, TID=4][22/27]> /opt/geant4/lib/libG4ptl.so.0(_ZN3PTL10ThreadPool14execute_threadEPNS_14VUserTaskQueueE+0x398) [0x7f8ea2efa208]
[PID=36088, TID=4][23/27]> /opt/geant4/lib/libG4ptl.so.0(_ZN3PTL10ThreadPool12start_threadEPS0_PSt6vectorISt10shared_ptrINS_10ThreadDataEESaIS5_EEl+0x215) [0x7f8ea2efa685]
[PID=36088, TID=4][24/27]> /lib/x86_64-linux-gnu/libstdc++.so.6(+0xdc2c3) [0x7f8ea6adc2c3]
[PID=36088, TID=4][25/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x94b43) [0x7f8ea6694b43]
[PID=36088, TID=4][26/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x126a00) [0x7f8ea6726a00]

Still I could have messed it up somewhere else in my application – I was just wondering whether you can make a statement about thread safety in general.
@fmauger
Copy link
Member

fmauger commented Oct 1, 2022

Hi Luigi,
Thanks for the report. BxDecay0 is not thread-safe by design. But my guess is that one can make it such on client side with some special care. I will have a look at this specific use case ASAP. This is an interesting topic and at least giving hints to users about that would be a plus. There are many ways to implement thread-safety and usually it depends on the client's specific context. I have never used G4.1X in MT mode (we run it in single thread mode on many independent machines and merge the output stats) so I can't tell you more about this specific usage within G4. Anyway, stay tuned, I put it in my todo list.

drbenmorgan added a commit to drbenmorgan/bxdecay0 that referenced this issue Jan 24, 2023
@drbenmorgan
Improve thread safety og static resources
926bbc2 
As reported in BxCppDev#28, bxdecay0 can produce segfaults when running as
the primary generator of a multithreaded Geant4 application. Triaged
in this use case to the use of statics in the pattern:

```
some_t function() {
  static thing_t thing;
  if (thing.not_init()) thing.fill();
  ...
  return thing;
}
```

Whilst C++11 guarantees the initialization of `thing` to be thread
safe (at least for standard types), the code following the init
statement is not. For example, a vector could be initialzed then
filled if empty, but multiple threads could contend over the scope
that does the filling.

Decouple static initialization by factoring the filling of the
static objects into separate functions. As the initialization
of the static is only called once, so is the initialization function
and thus removing thread contention issues.

Note that the BinReloc functions are not modified using this pattern,
but as the calls to these functions are only in bxdecay0::get_library_dir()
and its init function, these should be sufficiently protected. At worst
a lock_guard is needed in this one place.
@drbenmorgan drbenmorgan mentioned this issue Jan 24, 2023
Merged
@ManuelHu
Copy link

I think this issue can be closed. Tried with a current build of remage, and no crashes can be observed.

The "remaining thread-safety segfault" in remage described in #29 was probably another bug there, that I already fixed some time ago, so not of concern for BxDecay0.

@gipert gipert closed this as completed Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ManuelHu @fmauger @gipert