-
Notifications
You must be signed in to change notification settings - Fork 45
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
Racy test failure: segfault in map::tree_bins::concurrent_tree_bin #84
Comments
Also unable to reproduce on Windows stable as of now. The location makes me think of |
I need to leave now and will have to come back to this (and maybe setup a Linux nightly for testing). If you have time, maybe try this out in the meantime. |
Hmm, I wonder why the Java code does not have to deal with that... |
If this ends up being the cause, it would be because the reading thread holds a reference to the Thread handle in question, so it cannot get GC'd (they don't [have to] use atomic pointers) |
Ah, that's a good point. Let me try making that a deferred destroy. |
It is possible for someone to try to wake a waiting thread while that thread is spinning. In that case, the waiting thread may decide to free its waker just before the waking thread tries to wake the waiting one, resulting in a use-after-free. This fixes that by deferring the freeing of the waker until the next epoch. Seems to fix #84.
It is possible for someone to try to wake a waiting thread while that thread is spinning. In that case, the waiting thread may decide to free its waker just before the waking thread tries to wake the waiting one, resulting in a use-after-free. This fixes that by deferring the freeing of the waker until the next epoch. Seems to fix #84.
This is this issue which I've factored out into its own issue. Basically, the
map::tree_bins::concurrent_tree_bin
test occasionally segfaults for me without a backtrace. I can reproduce on current nightly on Linux by running this command for a while:$ while cargo test --lib map::tree_bins::concurrent_tree_bin -- --test-threads=1 --nocapture; do :; done
Using
gdb
, I managed to capture a stack trace:The text was updated successfully, but these errors were encountered: