Closed arvidn closed 4 years ago
What I'm not 100% convinced of is that the model thread sanitizer uses supports:
Sometimes I get the impression it expects all (shared) accesses to memory be made under a mutex lock.
It makes sense that thread sanitizer can't see the synchronization between the two threads. It looks like the sanitizer supports annotations specifically to inform it about these sorts of "hidden" barriers.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Please provide the following information
libtorrent version (or branch): RC_1_1 (with https://github.com/arvidn/libtorrent/pull/3081 https://github.com/arvidn/libtorrent/pull/3082 https://github.com/arvidn/libtorrent/pull/3083 applied)
platform/architecture: MacOS/x86_64
compiler and compiler version: clang++ (Apple LLVM version 9.1.0 (clang-902.0.39.2))
When running the
test_checking.cpp.discrete_checking
test under thread sanitizer (built withsanitize=thread
b2 option) the following race condition is detected.As far as I can tell, it's referring to the write to
disk_io_job::flags
here, which was previously written to from another thread here.I'm having a hard time understanding how this could be a race. The ownership of the job object is transferred from the main thread into the disk thread (pool). This transfer is synchronised with a mutex around the job queue. This issue seems to specifically call out the fence jobs though. The fence jobs are queued up as a blocked job instead of on the normal job queue, inside the
disk_job_fence
object. Once all normal jobs have been drained, it's issued. But it should still belong to thread pool at that point.@ssiloti or @aldenml do you have any suggestions or hints I can go look at?