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
Repeatable read violation with reverse iterator in memtx #7755
Comments
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Oct 1, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Oct 1, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Oct 2, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Oct 3, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Oct 12, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Oct 31, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Nov 9, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
alyapunov
pushed a commit
that referenced
this issue
Nov 30, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in #7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes #7755 Closes #7756 NO_DOC=bugfix
alyapunov
pushed a commit
that referenced
this issue
Nov 30, 2022
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in #7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes #7755 Closes #7756 NO_DOC=bugfix (cherry picked from commit 651535b)
CuriousGeorgiy
added a commit
to CuriousGeorgiy/tarantool
that referenced
this issue
Jun 16, 2023
We assumed that the successor tuple's story could not get garbage collected on clarify of result tuple in `tree_iterator_start`, since they coincide in case of regular iterators. But this is not the case for reverse iterators: the result tuple is of-by-one from the successor, which means the successor's story can get garbage collected along with the tuple itself getting deleted, leading to use-after-free of successor: remove garbage collection from `memtx_tx_tuple_clarify` and call it manually. The crash in tarantool#7756 revealed that the `put` in transaction manager's story hash table was performed incorrectly: fix it and add an assertion that nothing was replaced. Closes tarantool#7755 Closes tarantool#7756 NO_DOC=bugfix
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
Actual behavior
Expected behavior
The text was updated successfully, but these errors were encountered: