hashicorp / hashicorp/go-memdb
It can cause panic while running test data with some special
- 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