jormungandr: Leader failed to validate its own blocks
Mandatory Information
jcli 0.5.5 (master-c3f2dcc4+, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]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)
@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.