Skip to content
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.

Sign up for GitHub

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

Jump to bottom

LLVM thread sanitizer (TSAN): false positive in pthread_setcancelstate()? #2323

Closed
rgerhards opened this issue Dec 30, 2017 · 4 comments
Closed

LLVM thread sanitizer (TSAN): false positive in pthread_setcancelstate()? #2323

rgerhards opened this issue Dec 30, 2017 · 4 comments
Assignees
@rgerhards
Labels
QA
Milestone
v8.36

Comments

@rgerhards
Copy link
Member

We use TSAN together with clang (3,4,5) on Linux (in this Case Ubuntu 16.04). It works great, but I always get race reports (sample after my sig) on pthread_setcancelstate(). The POSIX doc states that it sets the cancellation state for the current thread so there should be no cross-thread data races. To validate this, I have also checked the GNU libc and pthread implemenation and the both access thread-local storage.

LLVM Mailing List Posting: http://lists.llvm.org/pipermail/cfe-users/2017-December/001215.html
@rgerhards rgerhards added the QA label Dec 30, 2017
@rgerhards rgerhards added this to the v8.33 milestone Dec 30, 2017
@rgerhards rgerhards self-assigned this Dec 30, 2017
rgerhards added a commit to rgerhards/rsyslog that referenced this issue Dec 30, 2017
@rgerhards
TSAN: tried to work around false positive pthread_setcancelstate
8e7625a 
Tried to use __attribute__((no_sanitize("thread"))) and blacklisting
to work around the issue, but without any success. Note that this commit
only contains the blacklisting file, but the proper compiler option was
set to use it.

see also rsyslog#2323
@rgerhards
Copy link
Member Author

rgerhards commented Dec 30, 2017 •
edited

OK, now stuck as rgerhards@8e7625a did not bring up any viable solution. Let's see if we find a solution via the LLVM mailing lists. Else we probably need to abandon the idea of using TSAN in automatted testing ;-(

@rgerhards rgerhards modified the milestones: v8.33, v8.34 Feb 15, 2018
@rgerhards rgerhards modified the milestones: v8.34, v8.35 Apr 3, 2018
@rgerhards rgerhards modified the milestones: v8.35, v8.36 May 14, 2018
@rgerhards
Copy link
Member Author

asked again, this time on the clang developer's list: http://lists.llvm.org/pipermail/cfe-dev/2018-May/057957.html

If we can't solve it now, this probably means we need to close the issue tracker as unresolved and need to stay away from using TSAN in CI runs.

@rgerhards
Copy link
Member Author

unfortunately this seems to be unresolvable, so we cannot use clang in CI testing.

@rgerhards rgerhards mentioned this issue Dec 24, 2018
Open
@lock
Copy link

lock bot commented Dec 26, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@rgerhards rgerhards

Labels
QA
Projects
None yet
Milestone
v8.36
Development

No branches or pull requests
1 participant
@rgerhards