-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when trying to open corrupted database #105
Comments
I tried to use
|
Without
|
Similar issue: boltdb/bolt#698 |
Here's my repro code: func readBackup(file string) error {
db, err := bolt.Open(file, 0600, &bolt.Options{Timeout: 1 * time.Second, ReadOnly: true})
if err != nil {
return err
}
defer db.Close()
db.View(func(tx *bolt.Tx) error {
if groups := tx.Bucket([]byte("groups")); groups != nil {
num := groups.Stats().KeyN
log.Printf("num: %v", num)
}
})
return nil
} Would be really nice if there was some way I could check to see if the backup was consistent before trying to read it. Ideally bbolt would be able to deal with truncated/corrupted files itself and not crash the entire process. |
Add code to recover. |
I am also running into the issue that cc @serathius - I saw you recently committed to the repo - who to ping? Is this repo still maintained? Edit: the address fault is a segmentation fault, not a panic, so I this can't even be recovered with |
@benma etcd project still has maintainers, however we are very stretched with work on etcd. We can review PR and fix bugs, but there is no active development on bbolt. |
With https://pkg.go.dev/runtime/debug#SetPanicOnFault , segmentation faults can be turned into panics. |
Agreed. Fixing corrupted db file is my top priority recently. The most important thing is to figure out how to reproduce the issue. It would be great if anyone provide clues on this. Please do not hesitate to ping me if you have any thoughts. Thanks. FYI. Recently we added a |
The DB (
I am almost sure that the corruption isn't caused by bbolt. The db file has 6 pages in total, but the bucket's root page is somehow a huge value 7631988 (0x747474). Most likely it's caused by other issues, e.g. hardware or OS issue? @benma Do you still remember how was the corrupt file generated? Was there anything unusual (e.g. power off, OS crash, etc.) when the corrupt file being generated? BTW, what's the bbolt version?
|
The corrupted file provided by @tmm1 seems like a potential bbolt bug. What's your bbolt version? The freelist page (108) was somehow reset (all fields have zero value). What's confusing is that two meta pages have exactly the same
|
There is even no way to fix the corrupted db file. The file is only 204800 bytes, so it's 50 pages ( 204800/4096 ). Obviously the root page ID (99), Freelist (108) and HWM (482) exceeds the file size. I can't even find the root page in the available 50 pages. It seems that the file was somehow truncated, and the root was in the truncated part.
|
I have an app that takes regular backups of boltdb databases. Sometimes, for unknown reasons, the backups are corrupted.
I also have a restore UI that lets me browse and read from backups. Trying to open and read from these corrupted databases crashes my process. I'm using 4f5275f
test.db.gz
The text was updated successfully, but these errors were encountered: