fix: locking bug when tracer reads from thunk in Load method #120
+66
−5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #119 !
I discovered that the deadlock happens as a result of #113 moving the
Unlock()calls on the batch mutexes to be adefer. This happens because the unlocks run after thedefer finish(thunk)is called for the tracer.The simplest way to fix this seems to be to simply revert the
deferstatements added in that PR, and keep everything else, from reading this code, I don't believe this should cause any other issues since no where else early returns in that function.I left a comment to give a little bit of context for whoever comes to refactoring that part next, and included a unit test which simulates the POC of the bug I created here, to ensure there isn't a regression accidentally introduced in the future.
Thanks!