-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Cannot run ord server after a crash due to cberner/redb#515 #1471
Comments
Nice, thanks for the report! We should leave this open, but if it's an issue with redb, then we're blocked on our end. Chris is a solo open source dev (and also a great guy!) so keep in mind that he might have limited resources to look into this. |
I've faced more panics and now I suspect that these crashes are a result of bugs in ord and redb. redb should not allow corrupted files. But, I can reproduce panics with Running
As always, i'm on the current master (10f8469). Are |
I interrupted a healthy
When I run it again, it increases the progress bar from 393,914 to 393,918, and panics with: Here's the trace:
|
I've snapshots at every 10k blocks.
Edit: One of those |
Start indexing from a snapshot at 590,000 and interrupt after a while:
Start indexing again. It interrupts shortly after:
Actually, the problem is not about interrupt. It can be replicated with gracefully stoping index even after a single block with
One may ask, why bother? Just keep indexing from Keeps indexing from 590,000. In that case, ord indexes until 595,000 where it panics. |
My snapshot at 590,000 is |
I think I know where the bug could be: index.redb could have wrong number of heights. I've also got a case that where the loaded index.redb starts the progress from blocks never processed. The index command panicked around 595,000 or 595,033:
Then, when I run the command again, the progress bar starts from 600,000 -- the height-limit of the previously panicked command:
|
I replicated this issue on different machines, operating systems (macOS & Ubuntu), and processors (M1, Xeon on computer and on AWS). I came across this over and over again: Let's say we've a snaphot
Now the The index.db size stays the same but changes its hash. |
I've seem similar issues when running on redb 12.1 from master. Downgraded to 11.0 (previously committed version) and have reached height 626500 FWIW. |
Can you guys confirm that this is an issue with redb 12.1, and it doesn't appear on 11.0? If so, we can downgrade master to 11.0 easily. We're not relying on any new features in 12.1. |
We're trying with redb master (cberner/redb@1293d4f) as suggested with @cberner. redb v0.11.0 doesn't have the suspected bug introduced by cberner/redb#476. |
FYI debug ENV var in Rust. example: |
Inconsistent start heights likely from commit and rollback transactions.
|
Definitely consider opening a discussion item like "how can i debug ord?" and then self-answer mentioning RUST_LOG. Also if it's not in the readme that would be a great PR. |
It was mentioned here by @casey ordinals#1471 (comment) that this small tips in REQDME could help a lot of folks.
A bug in the underlying db (cberner/redb#515) is preventing ord to run server after a crash.
I interrupted ord as it was indexing and seemed stuck at block 494299:
Afterwards, I cannot run ord again:
This index is created from scratch with the latest commit (casey@10f8469).
The text was updated successfully, but these errors were encountered: