-
Notifications
You must be signed in to change notification settings - Fork 31
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.
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
Data race reported by thread sanitizer #71
Comments
I opened PR #72 to add thread sanitizer, which also reports data race when dropping |
Hello Are you sure this one is not a false positive of the thread sanitizer? Last time I've spent several hours examining it, I've reached the conclusion the thread sanitizer somehow doesn't understand this synchronization pattern and doesn't see it, but I had a proof that it is correct according to the spec (it's even written in the code). I know there was some time since then, so maybe it's behaving better and this one may be legitimate, but I don't really have much time to spend 10 hours looking for something to finally prove that it is imperfection of the sanitizer. Would you be able to pinpoint it somewhat better? Having a smaller reproducer, or following the proof/code path and looking at where it happens? Same goes for the linked pull request… it would be nice for it to be green and to keep checking things, but as it is red now, it probably shouldn't go in yet before the issue is resolved. |
I am not so sure that this is not a false positive, given that it also reports data race in I am not so familiar with |
From a quick glance at the backtrace. This seems to happen during dropping of an Arc inside an allocator. Now, that happening in allocator is already somewhat suspicious. Nevertheless, I could imagine the allocator doing these things if I try to deallocate memory that wasn't „brought into“ the current thread. As in, one thread allocates some memory, passes the pointer to other thread without synchronization and the other thread deallocates. I believe this isn't the case in the test, for two reasons:
All in all, this seems to me to be either a false positive of the thread sanitizer, a bug in the allocator or some platform specific optimization in the allocator that is technically not correct according to the language spec but known to work on the given platform & compiler (platforms are allowed to provide stronger guarantees than the language and I wouldn't be surprised if things like allocators took advantage of that). I'll keep this open for now, so you or others can go and verify my claims. Also, trying the test with a different allocator could show us something (but I'm not sure what). |
Thanks for explanation and taking your time to investigate on this issue! If this is a bug in the allocator that does not work on the given platform, then maybe I can try to run the thread sanitizer on other platforms such as arm64 and tests its behavior. I can also try another allocator to see if it makes a difference. |
MacOS is able to run the thread sanitizer without any problem. This seems like to be a platform specific problem. |
Ok, then I'll close this one. |
I tried to run the tests of
arc-swap
using thread sanitizer using commandRUSTFLAGS='-Zsanitizer=thread' cargo +nightly test -Z build-std --target --target $(uname -m)-unknown-linux-gnu
and it reported data race when dropping theArc
intests_default::rcu
:I am using
cargo-1.58.0-nightly
on Linux:clang --version
gcc --version
:The text was updated successfully, but these errors were encountered: