it.Next() blowing up db during key iteration

Issues Badger
1

What version of Go are you using (go version)?

$ go version

1.16

What operating system are you using?

Alpine Linux: 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 Linux

for what its worth this is running in k8s

What version of Badger are you using?

tried v3.2011.1 & master (ec5b35e677c9c89bd6347bba5bf3f63ea063f723)

Does this issue reproduce with the latest master?

yes (ec5b35e677c9c89bd6347bba5bf3f63ea063f723)

Steps to Reproduce the issue

This seems to be similar (same as?) this fix(iterator): fix iterator when data does not exist in read only mode by NamanJain8 · Pull Request #1670 · dgraph-io/badger · GitHub

I dont fully understand what causes it, but this is our code:

var keys [][]byte
var err = store.db.View(func(txn *badger.Txn) error {
	opts := badger.DefaultIteratorOptions
	opts.PrefetchValues = false
	it := txn.NewIterator(opts)
	defer it.Close()
	for it.Rewind(); it.Valid(); it.Next() {
		var key []byte
		key = it.Item().KeyCopy(key)
		keys = append(keys, key)
	}
	return nil
})

We also tried db.Update() and got the same results.

What Badger options were set?

badger.DefaultOptions(dir).WithCompression(options.None).WithLogger(dbLogger)

What did you do?

Iterate over the keys

What did you expect to see?

The DB not crash

What did you see instead?

unexpected fault address 0x7f470435556e
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x7f470435556e pc=0x99beaa]
goroutine 5420 [running]:
runtime.throw(0x11d2d33, 0x5)
        /usr/local/go/src/runtime/panic.go:1116 +0x72 fp=0xc00e18d4a8 sp=0xc00e18d478 pc=0x437e12
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:749 +0x405 fp=0xc00e18d4d8 sp=0xc00e18d4a8 pc=0x44e3e5
encoding/binary.bigEndian.Uint32(...)
        /usr/local/go/src/encoding/binary/binary.go:113
github.com/dgraph-io/badger/v3/y.BytesToU32(...)
        /build/vendor/github.com/dgraph-io/badger/v3/y/y.go:273
github.com/dgraph-io/badger/v3/table.(*Table).block(0xc040903500, 0x285, 0x101, 0x0, 0x0, 0x0)
        /build/vendor/github.com/dgraph-io/badger/v3/table/table.go:587 +0x2ea fp=0xc0017216d8 sp=0xc0017214e0 pc=0x99be8a
github.com/dgraph-io/badger/v3/table.(*Iterator).next(0xc00f2e2380)
        /build/vendor/github.com/dgraph-io/badger/v3/table/iterator.go:331 +0xd0 fp=0xc001721728 sp=0xc0017216d8 pc=0x9976f0
github.com/dgraph-io/badger/v3/table.(*Iterator).next(0xc00f2e2380)
        /build/vendor/github.com/dgraph-io/badger/v3/table/iterator.go:348 +0x1ea fp=0xc001721778 sp=0xc001721728 pc=0x99780a
github.com/dgraph-io/badger/v3/table.(*Iterator).Next(0xc00f2e2380)
        /build/vendor/github.com/dgraph-io/badger/v3/table/iterator.go:406 +0x3e fp=0xc001721790 sp=0xc001721778 pc=0x997c7e
github.com/dgraph-io/badger/v3/table.(*ConcatIterator).Next(0xc0014f1900)
        /build/vendor/github.com/dgraph-io/badger/v3/table/iterator.go:529 +0x33 fp=0xc0017217f0 sp=0xc001721790 pc=0x998673
github.com/dgraph-io/badger/v3/table.(*node).next(0xc0014f60f0)
        /build/vendor/github.com/dgraph-io/badger/v3/table/merge_iterator.go:81 +0x3d fp=0xc001721808 sp=0xc0017217f0 pc=0x998cdd
github.com/dgraph-io/badger/v3/table.(*MergeIterator).Next(0xc0014f60b0)
        /build/vendor/github.com/dgraph-io/badger/v3/table/merge_iterator.go:157 +0x38 fp=0xc001721870 sp=0xc001721808 pc=0x9990d8
github.com/dgraph-io/badger/v3.(*Iterator).parseItem(0xc0014f6160, 0xc00f895401)
        /build/vendor/github.com/dgraph-io/badger/v3/iterator.go:690 +0x464 fp=0xc001721958 sp=0xc001721870 pc=0x9c1d84
github.com/dgraph-io/badger/v3.(*Iterator).Next(0xc0014f6160)
        /build/vendor/github.com/dgraph-io/badger/v3/iterator.go:594 +0x133 fp=0xc001721978 sp=0xc001721958 pc=0x9c1773
2

Hey @kmulvey, thanks for reaching out. It is not related to the PR you mentioned.
I hope you are not running the code over a DB created over older version.
Can you share the full code to reproduce it on our end? If you can’t share publicly, you can mail me at naman[at]dgraph.io
Thanks.

1 Like