tfork_atexit_unknown[1|2]:
No idea what triggers this, definitely not tfork itself.
tfork_pthread_get_specific:
Helgrind reports:
Possible data race during read of size 4 at 0x5141304 by thread #3
Locks held: none
at 0x50E602E: tfork_global_get (tfork.c:301)
by 0x50E69B1: tfork_create (tfork.c:737)
by 0x2F7419: tfork_thread (tfork.c:431)
by 0x4C35AC5: mythread_wrapper (hg_intercepts.c:389)
by 0x8D38593: start_thread (pthread_create.c:463)
by 0x9A70E6E: clone (clone.S:95)
This conflicts with a previous write of size 4 by thread #2
Locks held: none
at 0x8D3F7B7: pthread_key_create (pthread_key_create.c:41)
by 0x50E5F79: tfork_global_initialize (tfork.c:280)
by 0x8D3FEA6: __pthread_once_slow (pthread_once.c:116)
by 0x50E6999: tfork_create (tfork.c:728)
by 0x2F7419: tfork_thread (tfork.c:431)
by 0x4C35AC5: mythread_wrapper (hg_intercepts.c:389)
by 0x8D38593: start_thread (pthread_create.c:463)
by 0x9A70E6E: clone (clone.S:95)
Location 0x5141304 is 0 bytes inside global var "tfork_global_key"
declared at tfork.c:122
This is nonsense, tfork_global_get() calls pthread_getspecific, so
we're looking at the pthread_key_create()/pthread_[g|s]etspecific()
API here which works with threads by design.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
--- /dev/null
+{
+ tfork_atexit_unknown1
+ Helgrind:Misc
+ fun:mutex_destroy_WRK
+ fun:pthread_mutex_destroy
+ obj:/usr/lib64/libp11-kit.so.0.3.0
+ fun:_dl_fini
+ fun:__run_exit_handlers
+ fun:exit
+ fun:(below main)
+}
+
+{
+ tfork_atexit_unknown2
+ Helgrind:Misc
+ fun:mutex_destroy_WRK
+ fun:pthread_mutex_destroy
+ fun:_dl_fini
+ fun:__run_exit_handlers
+ fun:exit
+ fun:(below main)
+}
+{
+ tfork_pthread_get_specific
+ Helgrind:Race
+ fun:tfork_global_get
+ fun:tfork_create
+ fun:tfork_thread
+ fun:mythread_wrapper
+ fun:start_thread
+ fun:clone
+}