part: Fix bug with short and long key with shared prefix #22
Conversation
This file contains 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
If we insert "foobar" and then "foo" we ended up in a case where
"foo" was the common prefix and the rest of the key become empty
leading to out-of-bounds access to the key slice.
Handle the case where the key becomes empty when splitting a node
by just inserting it as the leaf of the split node.
Added a regression test and validated it catched the bug:
--- FAIL: Test_prefix_regression (0.00s)
panic: runtime error: index out of range [0] with length 0 [recovered]
panic: runtime error: index out of range [0] with length 0
goroutine 32 [running]:
testing.tRunner.func1.2({0x5f3380, 0xc00001a288})
/home/jussi/sdk/go1.22.0/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/home/jussi/sdk/go1.22.0/src/testing/testing.go:1634 +0x377
panic({0x5f3380?, 0xc00001a288?})
/home/jussi/sdk/go1.22.0/src/runtime/panic.go:770 +0x132
github.com/cilium/statedb/part.(*Txn[...]).insert(0x6725e0, ...
/home/jussi/go/src/github.com/cilium/statedb/part/txn.go:228 +0xdaf
Signed-off-by: Jussi Maki <[email protected]>
|
I think we need to switch the |
|
This exercises the underlying library in more ways than just using a fixed-length big endian uint64. Signed-off-by: Jussi Maki <[email protected]>
When leaf was moved from header to the node structs we missed setting the leaf when promoting/demoting. Signed-off-by: Jussi Maki <[email protected]>
|
Hm, race found another bug - investigating. |
Tests pass if the "mutated" cache is disabled. There's likely an issue related to leaf channels? Signed-off-by: Jussi Maki <[email protected]>
When deleting, we need to ensure that the target node watch channel is closed. However, if we mutated the node in the transaction already, we're looking at the cloned one, hence don't close the new channel too. The regression was found in the bigger hex iteration test, but reduced to: node4[]:(0xc00012a300) leaf[30]: 30 -> 0(0xc00014a410) node4[31]: 31 -> 1(0xc00012a360) leaf[30]: 3130 -> 2(0xc00014a550) leaf[31]: 3131 -> 3(0xc00014a5f0) After deleting 3 and 1 node4[]:(0xc00012a420) leaf[30]: 30 -> 0(0xc00014a410) node4[31]:(0xc00012a3c0) leaf[30]: 3130 -> 2(0xc00014a550 The channel of node4[31] was closed already, which is wrong. It was closed because we deleted 3, its child, and then deleted its leaf - which didn't clone the node again, but closed the new watch channel. Fixes: c7b7b15 (part: Fix missing closing of leaf watch channel) Reported-by: Jussi Maki <[email protected]> Signed-off-by: David Bimmler <[email protected]>
Signed-off-by: Jussi Maki <[email protected]>
joamaki
force-pushed
the
pr/joamaki/fix-shared-prefix-bug
branch
from
7b2d0f6 to
8e8fc3b
Compare
|
The second bug was that for non-leaf nodes we didn't return the old value. |
bimmlerd
approved these changes
Apr 29, 2024
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.
If we insert "foobar" and then "foo" we ended up in a case where "foo" was the common prefix and the rest of the key become empty leading to out-of-bounds access to the key slice.
Handle the case where the key becomes empty when splitting a node by just inserting it as the leaf of the split node.
Added a regression test and validated it catched the bug: