Ensure sender channel is not dropped until receiver reads exit request#82
Ensure sender channel is not dropped until receiver reads exit request#82kquick wants to merge 1 commit intotravitch:masterfrom
Conversation
| // point; if it was destroyed before the collect_events could read the | ||
| // `None` then the latter would instead get a Recv Error, causing | ||
| // failures to be reported. | ||
| drop(sender); |
There was a problem hiding this comment.
Hmm, I'm a bit skeptical that this was the issue - resources are freed at the end of their scope, which is somewhat after this drop. The join should have always joined before the channel was released before.
There was a problem hiding this comment.
The sender.send ends in a ?, which is a choice point that will end the basic block in which the send was called. Rust's Non-Lexical Lifetimes (NLL, https://rust-lang.github.io/rfcs/2094-nll.html) would then be able to conclude that since sender was unused in the remainder of the CFG that it could be removed at that point, which is prior to the thread join and could therefore open this race window.
Without explicit examination of the compilation output, I can't be sure of this, but NLL appears to be deployed (https://blog.rust-lang.org/2022/08/05/nll-by-default.html), so it is a likely culprit. Do you have any ideas for other culprits?
There was a problem hiding this comment.
Is the error you are observing occurring sporadically or deterministically?
I can't tell from the NLL RFC if it affects when destructors are called or if it is just about lifetime scope computation.
I'd just be really surprised if this was the culprit... in cases where sender.send(None) fails (i.e., ? causes the early return), that means the other thread already crashed (or some crazy OOM). That call might as well be .unwrap(). Maybe we should just do that?
In cases where it isn't crashing, the queue is definitely still live until the .join() returns (or the .unwrap() on that line fails).
There was a problem hiding this comment.
Oh and as for my hypothesis for the underlying cause: I think the real error might be in the ptrace code. I see Error: Tracee died while in ptrace-stop in #81. I am pretty confident that there is at least one gnarly race condition in the ptrace code (either in build-bom or the ptrace wrapper).
2 participants
This probably fixes #81, although that bug is intermittent and if this is indeed the fix, a race condition with a very small timing window, so it is not possible to be completely confident that this is the fix. However, this change should not have any negative effects.