Closed jonhoo closed 4 years ago
Also unable to reproduce on Windows stable as of now. The location makes me think of
the "race" discussed in https://github.com/jonhoo/flurry/pull/72#pullrequestreview-386441768 as a likely candidate. We talked about how the tokens are required because they might have to be available before the waiting threads park
s. However, your concern there may still be valid wrt. the reading thread seeing the stored WAITER
in lock_state
, the stored waiter
as non-null, but in the meantime the writing thread re-checks lock_state
and not only swaps out the waiter
, but cleans it up with into_owned
. Might need to be defer_destroy
, to handle the above case.
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.
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:Using
gdb
, I managed to capture a stack trace: