Skip to content
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

Closed
CuriousGeorgiy opened this issue Sep 30, 2022 · 0 comments · Fixed by #7759
Closed

Repeatable read violation with reverse iterator in memtx #7755

CuriousGeorgiy opened this issue Sep 30, 2022 · 0 comments · Fixed by #7759
Assignees
Labels
bug Something isn't working memtx mvcc

Comments

@CuriousGeorgiy
Copy link
Member

Steps to reproduce

os.execute('rm -rf *.snap *.xlog *.vylog 512')

local json = require('json')
local log = require('log')
local txn_proxy = require('txn_proxy')

box.cfg{memtx_use_mvcc_engine = true}

box.schema.space.create('s')
box.space.s:create_index('pk')

box.internal.memtx_tx_gc(1)

local tx1 = txn_proxy:new()
local tx2 = txn_proxy:new()
local tx3 = txn_proxy:new()

tx1('box.begin()')
tx2('box.begin()')
tx3('box.begin()')


tx1('box.space.s:insert{2}')
tx1('box.rollback()')

tx2('box.space.s:insert{0}')
log.info('%s', json.encode(tx3('box.space.s:select({1}, {iterator = "LE", fullscan = true})')))


box.space.s:insert{1}
log.info('%s', json.encode(tx3('box.space.s:select({1}, {iterator = "LE", fullscan = true})')))

os.exit()

Actual behavior

 ---
[[[1]]]
...

Expected behavior

 ---
[[]]
...
@CuriousGeorgiy CuriousGeorgiy added bug Something isn't working memtx teamC mvcc labels Sep 30, 2022
@CuriousGeorgiy CuriousGeorgiy self-assigned this Sep 30, 2022
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
Labels
bug Something isn't working memtx mvcc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant