-
-
Notifications
You must be signed in to change notification settings - Fork 657
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
thread race with itkImage::SetPixel() found with thread sanitizer (TSan) #4655
Comments
|
The test makes reference to JIRA issue number 3370:
Which is referenced in this commit: a18b3cf |
There is this issue: #3031. |
Ha! Totally forgot that I had apparently discovered this 2 years ago too!
Agreed.
I don't actually use this part of ITK, so I'm afraid I won't tackle it, with so many other things to do. But I would like to get |
I am suspicious of the algorithm implemented here: I am not sure how only the previous label line can be looked at to ensure they are not over lapping. |
This solves the |
Several ITK tests report errors with thread sanitizer. For several of them, the issue is the same.
itkImage::SetPixel()
is being used by different threads to write to the same memory location simultaneously. Even if each thread is writing the same value (I didn't check), this is still undefined behaviour (without an atomic write).If each thread is writing the same value, I think this could be fixed, on gcc/clang at least, by using
__atomic_store_n
and__atomic_load_n
inGetPixel
/SetPixel
. I tried, but couldn't figure out all the C++ templates to get down to the raw buffer.Long term, C++20
std::atomic_ref
could help too. (It's a wrapper of the aforemenioned compiler intrinsics.)For example, the test
itkStatisticsUniqueLabelMapFilterTest1
results in the following report:The text was updated successfully, but these errors were encountered: