it.Next() blowing up db during key iteration

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

$ go version


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?


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
        /usr/local/go/src/runtime/signal_unix.go:749 +0x405 fp=0xc00e18d4d8 sp=0xc00e18d4a8 pc=0x44e3e5
        /build/vendor/*Table).block(0xc040903500, 0x285, 0x101, 0x0, 0x0, 0x0)
        /build/vendor/ +0x2ea fp=0xc0017216d8 sp=0xc0017214e0 pc=0x99be8a*Iterator).next(0xc00f2e2380)
        /build/vendor/ +0xd0 fp=0xc001721728 sp=0xc0017216d8 pc=0x9976f0*Iterator).next(0xc00f2e2380)
        /build/vendor/ +0x1ea fp=0xc001721778 sp=0xc001721728 pc=0x99780a*Iterator).Next(0xc00f2e2380)
        /build/vendor/ +0x3e fp=0xc001721790 sp=0xc001721778 pc=0x997c7e*ConcatIterator).Next(0xc0014f1900)
        /build/vendor/ +0x33 fp=0xc0017217f0 sp=0xc001721790 pc=0x998673*node).next(0xc0014f60f0)
        /build/vendor/ +0x3d fp=0xc001721808 sp=0xc0017217f0 pc=0x998cdd*MergeIterator).Next(0xc0014f60b0)
        /build/vendor/ +0x38 fp=0xc001721870 sp=0xc001721808 pc=0x9990d8*Iterator).parseItem(0xc0014f6160, 0xc00f895401)
        /build/vendor/ +0x464 fp=0xc001721958 sp=0xc001721870 pc=0x9c1d84*Iterator).Next(0xc0014f6160)
        /build/vendor/ +0x133 fp=0xc001721978 sp=0xc001721958 pc=0x9c1773

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]

1 Like