hashicorp / hashicorp/go-memdb

It can cause panic while running test data with some special

Open
#92 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
3.5k
Forks
230
PR merge metrics
No merged PRs in 30d

Description

I found the test code below can cause the panic of DB, is any wrong with the test code?
```
type ritem struct {
Key string
Value []byte
}
base := []byte{1, 0, 1, 0}
key := append([]byte{}, base...)
minKey := []byte{1, 0, 1}

schema := &memdb.DBSchema{
Tables: map[string]*memdb.TableSchema{
"0": &memdb.TableSchema{
Name: "0",
Indexes: map[string]*memdb.IndexSchema{
"id": &memdb.IndexSchema{
Name: "id",
Unique: true,
Indexer: &memdb.StringFieldIndex{Field: "Key"},
},
},
},
},
}
mdb, err := memdb.NewMemDB(schema)
assert.Nil(t, err)

txn := mdb.Txn(true)
txn.Insert("0", &ritem{Key: string(key), Value: []byte("1")})
txn.Insert("0", &ritem{Key: string(append(key, byte(1))), Value: []byte("1")})
txn.Commit()

txn = mdb.Txn(false)
defer txn.Abort()
resIter, err := txn.LowerBound("0", "id", string(minKey)) // panic happened here
assert.Nil(t, err)
```

Contributor guide

No contributing guide indexed for this repository

Research direction

Reproduce the panic with the provided Go schema, byte keys, inserts, and read transaction, focusing on txn.LowerBound("0", "id", string(minKey)). Trace how LowerBound handles the special key prefix and determine the expected behavior; done means the example no longer panics and the behavior is covered by a regression test.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
databases
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.