-
Notifications
You must be signed in to change notification settings - Fork 18.1k
runtime: incorrect ordering on sync.RWMutex, possible optimization/defer bug #36864
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
Comments
Where is the reproducer? The
line doesn't look correct. Also does running |
I suppose @james-lawrence is referring to this one: https://github.com/james-lawrence/torrent.git |
To answer my own question: if the reproducer is the one at james-lawrence/torrent, it has indeed a data race. I ran:
and the output had this in it (among other things):
We cannot accept bug reports with racy reproducers (a program with a data race is not a valid Go program); so I'm closing this issue. If you can still reproduce the crash after you've fixed all the data-races, please comment and we'll re-open. Thanks. |
Uh oh!
There was an error while loading. Please reload this page.
I just want to preface that I fully expect this to be user error, given that
this class of bug would cause people to scream from the rooftops.
But I'm completely baffled. so putting this out there in case someone else has seen something similar.
this happens far more frequently in tests than actually running the program.
What version of Go are you using (
go version
)?1.13.7
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?What did you do?
I couldn't reproduce on the playground.
What did you expect to see?
expected the test complete with a standard pass/fail.
What did you see instead?
a panic due to unlock of an unlocked mutex.
what is important to note here is the line:
2020/01/29 06:27:58 chunks.go:214: 0xc000169060 unlock initiated - 4
there is no preceding log message relating to the lock being acquired or the function being invoked.
both log messages are executed before the unlock of the function occurs.
this simply shouldn't be happening, and I'm completely baffled as to why.
things I've checked:
example using synx.RWMutex directly without debugging code.
The text was updated successfully, but these errors were encountered: