Skip to content
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

Panic: hashes must be unique in memory_state #1182

Closed
teor2345 opened this issue Oct 19, 2020 · 2 comments · Fixed by #1198
Closed

Panic: hashes must be unique in memory_state #1182

teor2345 opened this issue Oct 19, 2020 · 2 comments · Fixed by #1198
Assignees
Labels
A-rust Area: Updates to Rust code C-bug Category: This is a bug
Projects

Comments

@teor2345
Copy link
Collaborator

teor2345 commented Oct 19, 2020

Version

zebrad main branch, 19 October 2020.

Platform

Linux ... 5.4.68 #1-NixOS SMP Sat Sep 26 16:03:16 UTC 2020 x86_64 GNU/Linux

Description

While syncing mainnet blocks, zebrad panicked with a "hashes must be unique" error in memory_state, inside the span zebra_state::service::queue_and_commit_non_finalized_blocks.

I tried this:

Partially syncing mainnet, a sync hang (#1181), then restarting zebrad so sync could continue.

I expected to see this happen:

A successful sync to the tip.

Instead, this happened: [explanation]

A block timeout error, followed by a zebra-state panic.

Metadata

key value
version 3.0.0-alpha.0

Block Download Error

Error: 
   0: failed to verify block
   1: request timed out

SpanTrace

SpanTrace:
   0: zebrad::components::sync::block_fetch_verify
           with hash=00000000024f9794d9cfe1d7ab6e7e23e7fa68dbc00316ea6e9a0c96358f73b4
             at zebrad/src/components/sync.rs:615
   1: zebrad::components::sync::extend_tips
             at zebrad/src/components/sync.rs:434
   2: zebrad::components::sync::sync
             at zebrad/src/components/sync.rs:169

State Error

hashes must be unique

SpanTrace

SpanTrace:
   0: zebra_state::service::queue_and_commit_non_finalized_blocks
             at zebra-state/src/service.rs:76
   1: zebrad::components::sync::block_fetch_verify
           with hash=000000000166f4b01559db2831189c088a99943ba2db2b40b4d068412ea16454
             at zebrad/src/components/sync.rs:615
   2: zebrad::components::sync::obtain_tips
             at zebrad/src/components/sync.rs:314
   3: zebrad::components::sync::sync
             at zebrad/src/components/sync.rs:169
@teor2345 teor2345 added C-bug Category: This is a bug A-rust Area: Updates to Rust code S-needs-triage Status: A bug report needs triage labels Oct 19, 2020
@teor2345 teor2345 added this to the First Alpha Release milestone Oct 19, 2020
@teor2345 teor2345 added this to To Do in 🦓 via automation Oct 19, 2020
@teor2345
Copy link
Collaborator Author

@yaahc I think you might have a better idea of what is going on with this state panic?

@yaahc
Copy link
Contributor

yaahc commented Oct 22, 2020

It's implying that the same block was inserted twice into the memory state I think, looking into it. I thought we already added the duplicate block handling but I might be misremembering.

edit: looks like we didn't, what am I thinking about then X_X

edit2: Oh yea, I found it, you edited the RFC about this, back on track

@yaahc yaahc moved this from To Do to In progress in 🦓 Oct 22, 2020
🦓 automation moved this from In progress to Done Oct 26, 2020
yaahc added a commit that referenced this issue Oct 26, 2020
## Motivation

The zebra-state service needs to be able to handle duplicate blocks.

## Solution

This implements changes already outlined by [The State
RFC](https://zebra.zfnd.org/dev/rfcs/0005-state-updates.html). We check for
successfully committed blocks first, since interacting with the queued blocks
struct at this point just complicates the implimentation. If the block has not
already been committed we then check if the block has already been queued, if
not we handle the block normally (normally here being the bit we already had
implemented).

## Documentation Changes

- [x] Update the state RFC to match the ways this fix departs from the design
	- the main thing is that I switched the order of checking for duplicates
- [x] ~~Add newly added functions to the state rfc~~ Decided not to do this because they're minor getters that don't influence the rest of the design and aren't exposed as part of the API
- [x] Document newly added functions inline

## Testing

## Related Issues

- fixes #1182
- tracking issue #1049

Co-authored-by: teor <teor@riseup.net>
@mpguerra mpguerra removed the S-needs-triage Status: A bug report needs triage label Feb 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rust Area: Updates to Rust code C-bug Category: This is a bug
Projects
No open projects
🦓
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants