Currently, when the compiler is configured with TSan enabled, only native programs are compiled with TSan instrumentation; bytecode programs produced by ocamlc are not. However, ocamlrun gets linked with the -fsanitize=thread flag. This is bad, because it causes some libc functions like mmap or memmove to be intercepted and replaced with special TSan versions, even though none of the OCaml nor C runtime is instrumented.
The consequences so far have been minor (we usually don’t use bytecode when TSan is enabled and vice versa), but it causes some occasional false alarms in the TSan CI, like lib-format/mc_pr586_par.ml, which has been flaky for a while. This false alarm is due to TSan seeing memory being accessed by the occasional memmove or strcpy, without any synchronization (because the synchronization operations are not instrumented).
Ideally, ocamlrun should not be linked with -fsanitize=thread.
Currently, when the compiler is configured with TSan enabled, only native programs are compiled with TSan instrumentation; bytecode programs produced by ocamlc are not. However,
ocamlrungets linked with the-fsanitize=threadflag. This is bad, because it causes some libc functions likemmapormemmoveto be intercepted and replaced with special TSan versions, even though none of the OCaml nor C runtime is instrumented.The consequences so far have been minor (we usually don’t use bytecode when TSan is enabled and vice versa), but it causes some occasional false alarms in the TSan CI, like
lib-format/mc_pr586_par.ml, which has been flaky for a while. This false alarm is due to TSan seeing memory being accessed by the occasionalmemmoveorstrcpy, without any synchronization (because the synchronization operations are not instrumented).Ideally,
ocamlrunshould not be linked with-fsanitize=thread.