Skip to content

ThreadSanitizer and libfork are not compatible #34

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

Open
UsernameLinde opened this issue Apr 15, 2025 · 2 comments
Open

ThreadSanitizer and libfork are not compatible #34

UsernameLinde opened this issue Apr 15, 2025 · 2 comments

Comments

@UsernameLinde
Copy link

libfork uses std::atomic_thread_fence which is not compatible with ThreadSanitizer.

If/when tracking down a problem in my code, it would be nice to not get false positives from libfork.

Has this problem been considered and is there something that can be done?

@ConorWilliams
Copy link
Owner

This is a hard problem, I think the only way forward I see is to have a macro which converts all atomics to sequential consistent and removes the barriers. Not something I'm that keen on though as it would be quite painful to maintain. Id be open to a PR

@UsernameLinde
Copy link
Author

I've pondered over this and converting atomics is not really something that looks tempting. Don't want to increase the future maintenance burden a lot. So I searched around and looked for other ways to make tsan happy.

I haven't dug through libforks code in detail, but if there is only atomic-fence and fence-atomic synchronization,
then perhaps it can be done with some extra macros using __tsan_acquire and __tsan_release from
https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/include/sanitizer/tsan_interface.h and the macros could expand to nothing unless tsan-checking is enabled at compile time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants