-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
panic (close of closed channel) in TestCallReceiverRpc #348
Comments
Per discussion on matrix: I am having a really hard time reproducing this, and it seems likely that #366 could have fixed this as well given the nature of the change (though I'm having a hard time reproducing it locally before that commit too). I'm going to close this one for now; we can re-open if we see it again, but otherwise this seems likely to turn into a wild goose chase. |
Re-opening; I just hit this again locally. I wasn't able to reproduce it a second time (ran the tests 700 times), but now we have some evidence that this is still there, and just incredibly rare. |
Is there any chance this might have been resolved by #396 or #406 ? I ask because this issue doesn't feel very actionable, and I would very much like an excuse to close it! 😅 If not, is there a low-effort approach we could take to flushing it out, e.g. running unit tests a few thousand times on a dev machine? Assuming we can't reproduce it, how do you feel about closing optimistically? |
I'm ok closing it until it comes up again. |
I hit this again, re-opening. The stack trace below starts in a different spot, but still ends in Client.Release, so that gives me some confidence that this isn't terribly specific to any one test, and is a more general bug with the way Clients work.
|
This will simplify transitioning to using the rc package for refcounting. Right now there is a bug where one of the tests is failing with an error about multiple shutdowns -- I think this is likely equivalent to capnproto#348 (the done channel is gone), but it seems to be deterministic now.
This Shutdown() is redundant with the one in clientPromise.shutdown(). When capnproto#348 was filed, this was a close() on the done channel instead of a call to ClientHook.Shutdown, but became the latter after merging calls and refs -- done was for the former, Shutdown() for the latter. I'm still not 100% sure why this used to be non-deterministic.
Per #346; haven't dug into this at all yet, but I assume this has been there and is just rare enough to have not cropped up before. It passed ~250 times in that run before failing...
https://github.com/capnproto/go-capnproto2/actions/runs/3537277747/jobs/5937100516#step:7:488
The text was updated successfully, but these errors were encountered: