Panics when opening a corrupted Badger DB

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

$ go version
go version go1.16.2 windows/amd64

What operating system are you using?

Windows 10 1903 (OS build 18362.1082)

What version of Badger are you using? v3.2011.1

Does this issue reproduce with the latest master?


Steps to Reproduce the issue

Simply open the DB with


The corrupted DB can be found in my gdrive (2.6MB):

What Badger options were set?


What did you do?

Calling badger.Open()

What did you expect to see?

Return an error showing the DB is corrupted

What did you see instead?

Panic in another goroutine, which I cannot recover.

panic: runtime error: index out of range [3] with length 0 [recovered]
== Recovering from initIndex crash ==
File Info: [ID: 38, Size: 408, Zeros: 408]
isEnrypted: false checksumLen: 0 checksum:  indexLen: 0 index: [] 
== Recovered ==

goroutine 80 [running]:*Table).initBiggestAndSmallest.func1.1(0xc0001c1aa0)
	C:/gocode/pkg/mod/ +0x165*Table).initBiggestAndSmallest.func1(0xc0001d6180)
	C:/gocode/pkg/mod/ +0x6e
panic(0x1d77ca0, 0xc0003bcd68)
	C:/go/src/runtime/panic.go:971 +0x49a
	C:/gocode/pkg/mod/*Table).readTableIndex(0xc0001d6180, 0x0, 0x8, 0xc0001c1a40)
	C:/gocode/pkg/mod/ +0x491*Table).initIndex(0xc0001d6180, 0x0, 0x0, 0xc0002a3260)
	C:/gocode/pkg/mod/ +0x545*Table).initBiggestAndSmallest(0xc0001d6180, 0x0, 0x0)
	C:/gocode/pkg/mod/ +0xab, 0x0, 0x200000, 0x0, 0x0, 0x3f847ae147ae147b, 0x1000, 0x0, 0x1, 0xc00053a080, ...)
	C:/gocode/pkg/mod/ +0x36e, 0xc0002b57b0, 0xc000589000, 0xc0002b5798, 0xc000178d10, 0x7, 0x7, 0xc00050a780, 0x21, 0x6, ...)
	C:/gocode/pkg/mod/ +0x2d8
created by
	C:/gocode/pkg/mod/ +0xc2b

hey @lukeng , it looks like all your sst files are empty.

du -sc db/*             
4	db/000002.sst
4	db/000004.sst
4	db/000006.sst
4	db/000008.sst
4	db/000010.sst
4	db/000012.sst
4	db/000014.sst

Did you modify these files? Badger shouldn’t be creating empty files.

Hi, I did not touch the files in the directory.

May it be created when I add and remove keys? I am using the DB as a cache and will periodically remove keys.

The crash is quite rare and it happens after I kill the app by force, not sure if it is related.

@lukeng The SST files are created/deleted by compaction but having 0 size SST is uncommon.
I think somehow your crash caused this.

@lukeng is there any way I can reproduce this problem? If you have a script or a program that I can use to reproduce this it would be very helpful.