Skip to content

SPV: Killing dash-evo-tool during initial sync causes panics on restart #429

@lklimek

Description

@lklimek

Summary:
Killing dash-evo-tool during initial sync in debug builds causes a panic on restart. This does not occur with release builds.

Steps to Reproduce:

  1. Start a debug build of dash-evo-tool at commit 7d1b8a361a8a3c7049525b891869523b63aa7738.
  2. Kill the process during the initial sync.
  3. Restart the tool.

Observed Behavior:

  • The tool panics on startup after being killed during initial sync (debug build only).
  • Release builds work as expected and do not panic on restart.

Stacktrace:

__rustc::rust_panic (@__rustc::rust_panic:6)
std::panicking::panic_with_hook (@std::panicking::panic_with_hook:70)
std::panicking::panic_handler::{{closure}} (@std::panicking::panic_handler::{{closure}}:43)
std::sys::backtrace::__rust_end_short_backtrace (@55555fddae79..55555fddaee1:3)
__rustc::rust_begin_unwind (@55555fdbdc9d..55555fdbdcff:3)
core::panicking::panic_fmt (@<*const T as core::fmt::Debug>::fmt:3)
dash_spv::storage::segments::SegmentCache<I>::get_items::{{closure}} (/home/lklimek/.cargo/git/checkouts/rust-dashcore-c6b13647c01f74b9/12ba186/dash-spv/src/storage/segments.rs:253)
<dash_spv::storage::block_headers::PersistentBlockHeaderStorage as dash_spv::storage::PersistentStorage>::open::{{closure}} (/home/lklimek/.cargo/git/checkouts/rust-dashcore-c6b13647c01f74b9/12ba186/dash-spv/src/storage/block_headers.rs:122)
<core::pin::Pin<P> as core::future::future::Future>::poll (/home/lklimek/.rustup/toolchains/1.92-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/future.rs:133)
dash_spv::storage::DiskStorageManager::new::{{closure}} (/home/lklimek/.cargo/git/checkouts/rust-dashcore-c6b13647c01f74b9/12ba186/dash-spv/src/storage/mod.rs:140)
dash_evo_tool::spv::manager::SpvManager::build_client::{{closure}} (/home/lklimek/git/dashevo/dash-evo-tool/src/spv/manager.rs:1396)
dash_evo_tool::spv::manager::SpvManager::run_spv_loop::{{closure}} (/home/lklimek/git/dashevo/dash-evo-tool/src/spv/manager.rs:857)
dash_evo_tool::spv::manager::SpvManager::start::{{closure}}::{{closure}} (/home/lklimek/git/dashevo/dash-evo-tool/src/spv/manager.rs:449)
<core::pin::Pin<P> as core::future::future::Future>::poll (/home/lklimek/.rustup/toolchains/1.92-x86_64-unknown-linux-gnu/lib/rustlib/src/future/future.rs:133)
tokio::runtime::park::CachedParkThread::block_on::{{closure}} (/home/lklimek/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/park.rs:284)
tokio::task::coop::with_budget (/home/lklimek/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/task/coop/mod.rs:167)
tokio::task::coop::budget (/home/lklimek/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/task/coop/mod.rs:133)
tokio::runtime::park::CachedParkThread::block_on (/home/lklimek/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/park.rs:284)
tokio::runtime::context::blocking::BlockingRegionGuard::block_on (/home/lklimek/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/context/blocking.rs:66)
tokio::runtime::scheduler::multi_thread::MultiThread::block_on::{{closure}} (/home/lklimek/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/multi_thread/mod.rs:89)

Additional Notes:

  • Affects only debug builds; release builds restart without panicking.
  • Stacktrace points to segment/block header storage in dash-spv.
  • May indicate missing error handling or state recovery on abrupt shutdown.
  • Possibly related: feat: validate stored data on startup #398

Environment:

  • dash-evo-tool commit: 7d1b8a361a8a3c7049525b891869523b63aa7738
  • Platform: Linux (rustc 1.92, debug)
  • dash-spv revision: 12ba186 (via .cargo/git/checkouts)

Impact:

  • Developer/CI usability: restarting after a crash requires manual cleanup.
  • Could mask underlying data corruption or error handling issue in SPV storage.

Expected Behavior:

  • After a kill during sync, startup should handle storage/segment recovery gracefully in both debug and release builds; panics should be avoided.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions