-
Notifications
You must be signed in to change notification settings - Fork 13.4k
std: Fix a TLS destructor bug on OSX #26958
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
Conversation
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
r? @brson I'll be honest in saying that I don't think I fully grasp the ramifications of this behavior on OSX, and it may be the case the are more problems lurking. Regardless the checked in test fails reliably beforehand and passes afterwards on OSX, so I figure this can't hurt to at least move forward a bit! |
@bors r+ This is some terrifying code. |
📌 Commit bd5a78d has been approved by |
⌛ Testing commit bd5a78d with merge 8edb9f1... |
💔 Test failed - auto-linux-64-nopt-t |
TLS tests have been deadlocking on the OSX bots for quite some time now and this commit is the result of the investigation into what's going on. It turns out that a value in TLS which is being destroyed (e.g. the destructor is run) can be reset back to the initial state **while the destructor is running** if TLS is re-accessed. To fix this we stop calling drop_in_place on OSX and instead move the data to a temporary location on the stack.
bd5a78d
to
987dc84
Compare
TLS tests have been deadlocking on the OSX bots for quite some time now and this commit is the result of the investigation into what's going on. It turns out that a value in TLS which is being destroyed (e.g. the destructor is run) can be reset back to the initial state **while the destructor is running** if TLS is re-accessed. To fix this we stop calling drop_in_place on OSX and instead move the data to a temporary location on the stack.
TLS tests have been deadlocking on the OSX bots for quite some time now and this
commit is the result of the investigation into what's going on. It turns out
that a value in TLS which is being destroyed (e.g. the destructor is run) can be
reset back to the initial state while the destructor is running if TLS is
re-accessed.
To fix this we stop calling drop_in_place on OSX and instead move the data to a
temporary location on the stack.