jormungandr: Leader failed to validate its own blocks

Mandatory Information

  1. jcli 0.5.5 (master-c3f2dcc4+, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]
  2. jormungandr 0.5.5 (master-c3f2dcc4+, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]

To Reproduce

$RUST_BACKTRACE=1 jormungandr --config node-config.yaml --genesis-block-hash adbdd5ede31637f6c9bad5c271eec0bc3d0cb9efb86a5b913bb55cba549d07
70 --secret node-secret.yaml --log-level debug
   0: error_chain::backtrace::imp::InternalBacktrace::new
   1: <error_chain::State as core::default::Default>::default
   2: jormungandr::blockchain::chain::Blockchain::post_check_header
   3: futures::future::chain::Chain<A,B,C>::poll
   4: futures::future::chain::Chain<A,B,C>::poll
   5: <futures::future::map::Map<A,F> as futures::future::Future>::poll
   6: futures::task_impl::std::set
   7: std::thread::local::LocalKey<T>::with
   8: futures::future::Future::wait
   9: jormungandr::blockchain::process::handle_input
  10: <futures::stream::for_each::ForEach<S,F,U> as futures::future::Future>::poll
  11: std::panicking::try::do_call
  12: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  13: <futures::future::catch_unwind::CatchUnwind<F> as futures::future::Future>::poll
  14: <futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll
  15: futures::task_impl::std::set
  16: std::panicking::try::do_call
  17: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  18: tokio_threadpool::task::Task::run
  19: tokio_threadpool::worker::Worker::run_task
  20: tokio_threadpool::worker::Worker::run
  21: std::thread::local::LocalKey<T>::with
  22: std::thread::local::LocalKey<T>::with
  23: std::thread::local::LocalKey<T>::with
  24: tokio::runtime::threadpool::builder::Builder::build::{{closure}}
  25: std::thread::local::LocalKey<T>::with
  26: std::thread::local::LocalKey<T>::with
  27: std::sys_common::backtrace::__rust_begin_short_backtrace
  28: std::panicking::try::do_call
  29: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  30: core::ops::function::FnOnce::call_once{{vtable.shim}}
  31: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/boxed.rs:787
  32: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/boxed.rs:787
      std::sys_common::thread::start_thread
             at src/libstd/sys_common/thread.rs:13
      std::sys::unix::thread::Thread::new::thread_start
             at src/libstd/sys/unix/thread.rs:79
  33: start_thread
  34: __clone
) } })
thread 'leadership0' panicked at 'Expect the event to not close', src/libcore/option.rs:1166:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 22 (11 by maintainers)

Most upvoted comments

@ilap You are correct, there should be proper error handling instead of a panic on invalid input, and we still have a few places that were left with a quick and dirty unwrap.

I am experiencing the same issue. It only happens /w a registered stake pool. But why does a node panic when a Block’s header verification failed (message is corrupted, invalid or any other issues with any incoming data)?

As, every node, at least, should be highly resilient (would say silver-bullet-proof) to any message they’re receiving from any (adversary or friendly) nodes or servers as otherwise the whole network can be shut down /w some malformed message.