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
[TSan] Random failure of tests/parallel/domain_dls.ml
#13059
Comments
So, in principle, these accesses being concurrent should be ok. The question is why our machinery based My feeling is that the unaligned nature of the load does not change anything to the fact that these accesses are safe In Practice™: the GC marking does not modify the tag. So the question is whether there is way to remove this false report. |
Well I'd argue that, on platforms requiring strict alignment of data such as |
If I understand @dustanddreams' point, the recommend fix would be to change the definitions of the |
Unsure if this is related, but 4 days ago I observed a crash in our |
Interesting, I don’t know much about unaligned accesses. How are they different in, for instance, amd64? |
I think we have a misunderstanding of what "unaligned access" means here. An unaligned access is a memory access of width Now if you consider atomicity, aligned read accesses not larger than the width of the memory bus (usually at least as wide as the machine register, but sometimes wider, e.g. the 88110 was a 32-bit processor with a 64-bit memory bus and able to perform atomic loads of 64-bit values into register pairs) are always atomic (well, except on alpha without the BWX extension, but these are not supported by the native compiler since 4.x). On the other hands, aligned write accesses are atomic only if they have the same width as the memory bus, or if the hardware provides some atomicity guarantees, since smaller-than-width writes will be turned into a 3-step read, modify the subset bytes, write operation. (which is why the x86 architecture has the "LOCK" prefix to require the memory bus to not be released between these steps, in order to appear to be an atomic operation to other devices). I will work on a relaxed version of |
Fixed by #13067. |
On s390x, sometimes (roughly one time out of three),
tests/parallel/domain_dls.ml
triggers a TSan alarm:I have not been able to observe a similar failure on other platforms.
The text was updated successfully, but these errors were encountered: