fix(linter/plugins): prevent comments being accessed after file is linted
#14727
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
Member
Author
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
github-actions
bot
added
A-linter
CodSpeed Performance ReportMerging #14727 will not alter performanceComparing Summary
Footnotes |
graphite-app
bot
changed the base branch from
10-17-refactor_linter_plugins_rename_function
to
graphite-base/14727
Member
Author
Merge activity
|
Member
Author
|
cc @lilnasy FYI. I didn't spot this before. Highly unlikely this would be a problem in practice, but I think worth covering all bases... |
…linted (#14727) Follow on after #14637. I now realize that there was a subtle race condition. We use `astId` counter in the getter for `program.comments`, to check that the getter is not called after that AST is done with. Buffers are reused, so the buffer held in local reference is the same, but the *contents* of the buffer could have changed - it may now contain a *different* AST. Previously, `astId` was incremented in `deserializeProgram`. So if `comments` getter is accessed after another AST is deserialized, it (rightly) throws. But there's a small period of time in between walking the AST on JS side and the *next* call to `deserializeProgram`. During that period, the buffer may be being mutated on Rust side (in another thread), but `astId` hasn't been incremented yet, so the `localAstId === astId` check in `comments` getter will pass, and it won't throw an error as it should. Fix this by incrementing `astId` as soon as traversal of *this* AST ends, instead of before deserializing the *next* AST begins.
graphite-app
bot
force-pushed
the
10-17-fix_linter_plugins_prevent_comments_being_accessed_after_file_is_linted
branch
from
5d6165e to
47d8db1
Compare
graphite-app
bot
deleted the
10-17-fix_linter_plugins_prevent_comments_being_accessed_after_file_is_linted
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Follow on after #14637. I now realize that there was a subtle race condition.
We use
astIdcounter in the getter forprogram.comments, to check that the getter is not called after that AST is done with. Buffers are reused, so the buffer held in local reference is the same, but the contents of the buffer could have changed - it may now contain a different AST.Previously,
astIdwas incremented indeserializeProgram. So ifcommentsgetter is accessed after another AST is deserialized, it (rightly) throws.But there's a small period of time in between walking the AST on JS side and the next call to
deserializeProgram. During that period, the buffer may be being mutated on Rust side (in another thread), butastIdhasn't been incremented yet, so thelocalAstId === astIdcheck incommentsgetter will pass, and it won't throw an error as it should.Fix this by incrementing
astIdas soon as traversal of this AST ends, instead of before deserializing the next AST begins.