-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Fix race in Diff printer #654
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
base: master
Are you sure you want to change the base?
Conversation
|
The problem is when the object to print has a mutex, and another goroutine is locking or unlocking the mutex, the sprintf will race. There is not a clear solution to fix this in all cases. At least for the common case of tests passing, this could skip the sprintf of the |
|
this one doesn't completely fix the issue but it helps, I think it should be merged for now. this issue is very frustrating |
|
@georgelesica-wf can you take a look at this one? |
|
When I revert the changes to |
|
@georgelesica-wf are you running the tests with |
This is after I removed the changes made to |
|
@georgelesica-wf 👋 I'm the original author of that test. I haven't checked the test on latest master, but I can relatively reliably get it to fail on the commit that added the test. As you may know, the race detector can have false negatives, but is guaranteed to not have false positives. When I checkout the commit that added the test and then run |
glesica
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm thank you for your contribution, sorry it took so long!
Print "FAIL" upon failure, not "PASS"
|
Note: the same race condition is still there, and always has been. It became more likely to occur with PR #596. This PR restores the order of sprintf calls to how it was before #596, which triggers the race condition less often, at least when using the latest go runtime at the time this was written. Some people will continue to have race failures. |
|
The However, there is a race condition on master when a mocked function with a
There is no race on the first call in |
Fixes #625
Race conditions were triggered when Sprintf-ing certain objects when preparing a diff for mock failures.
This restores the order of sprintf(obj) calls to the order it was prior to the race condition appearing.
Incorporates a new test case from @bhcleek