arithmetic operation overflow on ARM

[MagaTailor]

I left Parity/v1.2.0-unstable-69c29fc-20160620/arm-linux-gnu/rustc1.11.0-dev running but later found out it'd crashed (I guess it must have been close to fully synced at the time).

Not sure if it's a random crash related to an HDD connected via USB (there are huge amounts of DEBUG messages in the logs relating to DMA) or a real issue. My guess is the world may have stopped due to lots of SD card syslog writes which in turn could have starved parity.

#1747187 4618…f00f      1 blk/s    5 tx/s   0 Mgas/s    1/ 7 peers   #1747190     0+    0 Qed     46 MiB db   11 MiB chain    2 KiB queue   36 KiB sync

thread 'IO Worker #2' panicked at 'arithmetic operation overflow', util/bigint/src/uint.rs:1137
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Aborted

Restarting parity works fine again without any corruptions, getting to fully synced again.

[MagaTailor]

Probably not relevant, but parity may have been started with ionice -c3 followed by an

rm ~/.parity/906a34e69aec8c0d/v5.3-sec-overlayrecent/*/LOG*

shortly afterwards.

[arkpar]

more detailed stack trace:

thread 'IO Worker #0' panicked at 'arithmetic operation overflow', util/bigint/src/uint.rs:1137
stack backtrace:
   1:        0x10ddec2e8 - std::sys::backtrace::tracing::imp::write::h4c73fcd3363076f5
   2:        0x10ddf1175 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0422dbb3077e6747
   3:        0x10ddf0dae - std::panicking::default_hook::haac48fa641db8fa2
   4:        0x10ddd6ee6 - std::sys_common::unwind::begin_unwind_inner::h39d40f52add53ef7
   5:        0x10d859ae4 - std::sys_common::unwind::begin_unwind::hd78480d5ec5c51b2
   6:        0x10d9dae78 - ethcore::miner::transaction_queue::TransactionQueue::replace_transaction::h8947c7070d07fb8e
   7:        0x10d898c21 - ethcore::miner::transaction_queue::TransactionQueue::import_tx::hbcb23ff7ae28fe95
   8:        0x10d92374a - _<std..iter..Map<I, F> as std..iter..Iterator>::next::h76cf004bbf0485af
   9:        0x10d8df70f - _<service..ClientIoHandler as util..IoHandler<util..NetworkIoMessage<service..SyncMessage>>>::message::h4df26881121c14a5
  10:        0x10d8b50c9 - std::sys_common::unwind::try::try_fn::ha7a42f50113a05b9
  11:        0x10ddeb54b - __rust_try
  12:        0x10ddeb4d3 - std::sys_common::unwind::inner_try::h9eebd8dc83f388a6
  13:        0x10d8b63c7 - _<F as std..boxed..FnBox<A>>::call_box::he02889aa0ecf61a8
  14:        0x10ddf0308 - std::sys::thread::Thread::new::thread_start::h471ad90789353b5b
  15:     0x7fff9549f99c - _pthread_body
  16:     0x7fff9549f919 - _pthread_start

[MagaTailor]

So, what was triggering the overflow?

[tomusdrw]

It was an error in transaction queue. It happened when old transaction was imported (nonce - state_nonce < 0)

[MagaTailor]

Ah, thx; great to hear it wasn't related to any low level IO problems :)