Parity crashes with sample Tendermint chain spec

[d10r]

Parity crashes reproducibly when run with the tendermint chain spec in ethcore/res/tendermint.json (only network name changed and the 2 validator addresses replaced).

See attached logs of the 2 nodes (trace for engine enabled):
validator1.log
validator2.log

Probably relevant: force_sealing = true is set in the node config files.

Meanwhile, tests succeeds without error:

$ cargo test --package ethcore -- engines::tendermint
    Finished dev [unoptimized + debuginfo] target(s) in 0.1 secs
     Running target/debug/deps/ethcore-669d99ba57f879fe

running 15 tests
test engines::tendermint::message::tests::encode_step ... ok
test engines::tendermint::message::tests::encode_decode ... ok
test engines::tendermint::message::tests::proposal_message ... ok
test engines::tendermint::message::tests::step_ordering ... ok
test engines::tendermint::message::tests::generate_and_verify ... ok
test engines::tendermint::tests::can_return_schedule ... ok
test engines::tendermint::tests::can_generate_seal ... ok
test engines::tendermint::tests::can_recognize_proposal ... ok
test engines::tendermint::tests::has_valid_metadata ... ok
test engines::tendermint::tests::allows_correct_proposer ... ok
test engines::tendermint::tests::relays_messages ... ok
test engines::tendermint::tests::verification_fails_on_short_seal ... ok
test engines::tendermint::tests::seal_signatures_checking ... ok
test engines::tendermint::tests::epoch_verifier_verify_light ... ok
test engines::tendermint::tests::seal_submission ... ok

test result: ok. 15 passed; 0 failed; 0 ignored; 0 measured; 296 filtered out

   Doc-tests ethcore

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out

Parity/v1.10.0-unstable-048ff40-20180116/x86_64-linux-gnu/rustc1.25.0-nightly
Ubuntu 16.04
Compiled from source

The issue remains when compiling with the stable rust toolchain or when running a binary release of Parity.

[5chdn]

2018-01-29 23:24:46  IO Worker #0 TRACE engine  Proposer nonce: 3
2018-01-29 23:24:47  Verifier #1 TRACE engine  Proposer nonce: 2
2018-01-29 23:24:47  Verifier #1 DEBUG engine  Received a new proposal VoteStep { height: 2, view: 0, step: Propose } from eb6e…796f.

====================

stack backtrace:
   0:     0x55aa37faa134 - backtrace::backtrace::libunwind::trace::h62a4676581e6cea1
                        at /home/didi/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/backtrace-0.3.3/src/backtrace/libunwind.rs:53
                         - backtrace::backtrace::trace::ha864f99b114550dc
                        at /home/didi/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/backtrace-0.3.3/src/backtrace/mod.rs:42
   1:     0x55aa37fa063c - backtrace::capture::Backtrace::new_unresolved::h6ee5679cca037de1
                        at /home/didi/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/backtrace-0.3.3/src/capture.rs:88
   2:     0x55aa37fa058e - backtrace::capture::Backtrace::new::heeb4a047402b986d
                        at /home/didi/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/backtrace-0.3.3/src/capture.rs:63
   3:     0x55aa35f83688 - panic_hook::panic_hook::he14da82493d3e089
                        at panic_hook/src/lib.rs:53

Thread 'IO Worker #0' panicked at 'Invalid header.: RlpIsTooShort', libcore/result.rs:945

This is a bug. Please report it at:

    https://github.com/paritytech/parity/issues/new

Aborted (core dumped)

[d10r]

I'm trying to debug this myself, but - being new to Rust - have troubles finding a viable workflow. Even with incremental compilation enabled, small changes (e.g. in a testcast) typically take half a minute and more to re-compile and run.
Do you Parity devs have a good stategy for speeding that up (documented somewhere?) or just powerful dev machines?

[5chdn]

Unfortunately, compiling times is a well-known annoyance here. I do not know of any good workaround.