Crashes with thread 'IO Worker #3' panicked at 'nonce will return Some when given BlockId::Latest. nonce was given BlockId::Latest. Therefore nonce has returned Some; qed'

[jefffreey]

Using Ubuntu 16.04 and Parity/v1.6.8-beta-c396229-20170608/x86_64-linux-gnu/rustc1.17.0

While syncing the Kovan testnet, it crashes with the following output:

...
#2404625    0/ 1/25 peers     7 MiB db   71 KiB chain  0 bytes queue   10 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
thread 'IO Worker #3' panicked at 'nonce will return Some when given BlockId::Latest. nonce was given BlockId::Latest. Therefore nonce has returned Some; qed', /checkout/src/libcore/option.rs:785
stack backtrace:
  0: <unknown>
  1: <unknown>
  2: <unknown>
  3: <unknown>
...
 17: <unknown>
Aborted (core dumped)

[tomusdrw]

Did you try to send transaction while syncing (or play with transaction sending dialog in GUI)? Possibly trying to get a nonce from a state that got pruned away?

[jefffreey]

Nope. I was just waiting for it to sync. The problem still persists by the way, also without the ui flag. It crashes after printing 3 rows of information, such as:

2017-07-05 00:14:47  Starting Parity/v1.6.8-beta-c396229-20170608/x86_64-linux-gnu/rustc1.17.0
2017-07-05 00:14:47  State DB configuration: fast
2017-07-05 00:14:47  Operating mode: active
2017-07-05 00:14:47  Configured for Kovan using AuthorityRound engine
2017-07-05 00:14:47  Updated conversion rate to Ξ1 = US$269.15 (442309570 wei/gas)
2017-07-05 00:14:54  Public node URL: enode://b59647e4...
2017-07-05 00:14:54  Syncing #2404625 1521…03ea     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #2404625    0/ 8/25 peers     7 MiB db   71 KiB chain  0 bytes queue   10 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
2017-07-05 00:14:59  Syncing #2404625 1521…03ea     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #2404625    0/ 8/25 peers     7 MiB db   71 KiB chain  0 bytes queue   10 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
2017-07-05 00:15:04  Syncing #2404625 1521…03ea     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #2404625    0/ 8/25 peers     7 MiB db   71 KiB chain  0 bytes queue   10 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
thread 'IO Worker #1' panicked at 'nonce will return Some when given BlockId::Latest. nonce was given BlockId::Latest. Therefore nonce has returned Some; qed', /checkout/src/libcore/option.rs:785

[jonquach]

I have the same issue, on macOS

2017-07-10 02:23:14  Starting Parity/v1.6.8-beta-c396229-20170608/x86_64-macos/rustc1.17.0
2017-07-10 02:23:14  State DB configuration: fast
2017-07-10 02:23:14  Operating mode: active
2017-07-10 02:23:14  Configured for Foundation using Ethash engine
2017-07-10 02:23:14  Updated conversion rate to Ξ1 = US$237.29 (501696740 wei/gas)
2017-07-10 02:23:14  Public node URL: enode://a2046ec9feef31d091b5737c5905d5651db26e1db9680fc2655624c7f26c81885b6feb7701088f5012b2bed9a53771c15ce77dcfae48536856f9cb11975ac131@192.168.0.50:30303
2017-07-10 02:23:22  Block import failed for #4000574 (2345…ba16)
Error: Execution(InvalidNonce { expected: 0, got: 4 })
2017-07-10 02:23:24  Syncing #4000573 f89a…fc4d     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #4000573    5/10/25 peers    18 MiB db   74 KiB chain  0 bytes queue   12 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
thread 'IO Worker #0' panicked at 'nonce will return Some when given BlockId::Latest. nonce was given BlockId::Latest. Therefore nonce has returned Some; qed', src/libcore/option.rs:785
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::option::expect_failed
   9: ethcore::client::traits::BlockChainClient::latest_nonce
  10: <ethcore::miner::miner::TransactionDetailsProvider<'a> as ethcore::miner::transaction_queue::TransactionDetailsProvider>::fetch_account
  11: ethcore::miner::transaction_queue::TransactionQueue::add_internal
  12: ethcore::miner::miner::Miner::add_transactions_to_queue
  13: <ethcore::miner::miner::Miner as ethcore::miner::MinerService>::import_external_transactions
  14: ethcore::client::client::Client::import_queued_transactions
  15: std::panicking::try::do_call
[1]    64542 abort      parity --geth

I wanted to sync usign the --geth option but it keeps crashing, I also tried without it, but it still crash.

[5chdn]

Does this still happen with 1.7.0?

[hheeb]

Just happened to me with version 1.7.2 beta on a PC:

thread ‘IO Worker #1’ panicked at ‘nonce will return Some when given BlockId::latest. Nonce was given BlockId::latest. Therefore nonce has returned Some; qed’, src\libcore\option.rs:823

[5chdn]

Assigning to @rphmeier he has written QED 3c7e4b8#diff-3465bc775978072092164dda354243b6 :-P

[rphmeier]

yes, and it's still accurate IMO. This indicates a corrupted state, or perhaps being out of disk space

[miningpoolhub]

Similar error from Parity/v1.7.8-unstable-d5fcf3b-20171025/x86_64-linux-gnu/rustc1.19.0

2018-01-06 19:16:07 UTC Syncing #4861127 6227…19c3     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #4860616    6/25 peers    6 MiB chain  871 MiB db  0 bytes queue  169 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
2018-01-06 19:16:17 UTC Syncing #4861127 6227…19c3     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #4860839    9/25 peers    7 MiB chain  871 MiB db  0 bytes queue    8 MiB sync  RPC:  0 conn,  0 req/s,   0 µs
thread 'IO Worker #1' panicked at 'nonce will return Some when given BlockId::Latest. nonce was given BlockId::Latest. Therefore nonce has returned Some; qed', /checkout/src/libcore/option.rs:823
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:471
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:69
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:823
  10: ethcore::client::traits::BlockChainClient::latest_nonce
  11: <ethcore::miner::miner::TransactionDetailsProvider<'a> as ethcore::miner::transaction_queue::TransactionDetailsProvider>::fetch_account
  12: ethcore::miner::transaction_queue::TransactionQueue::add_internal
  13: ethcore::miner::miner::Miner::add_transactions_to_queue
  14: <ethcore::miner::miner::Miner as ethcore::miner::MinerService>::import_external_transactions
  15: ethcore::client::client::Client::import_queued_transactions

[gituser]

I had the same bug with parity v1.9.6:

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

stack backtrace:
   0:     0x564ee8cce9ac - backtrace::backtrace::trace::h46b3a13da4bc326d
   1:     0x564ee8ccd262 - backtrace::capture::Backtrace::new::h0c913169d6a9790c
   2:     0x564ee831cd6b - panic_hook::panic_hook::hd88826e8d45f8f4b

Thread 'IO Worker #3' panicked at 'All transactions in `current` and `future` are always included in `by_hash`', libcore/option.rs:917

This is a bug. Please report it at:

Any update when there will be a fix?

[folsen]

@gituser This is not the same issue as the one you have reported, the error message for the others is

nonce will return Some when given BlockId::Latest. nonce was given BlockId::Latest. Therefore nonce has returned Some; qed

and your error message is

All transactions in current and future are always included in by_hash

Please open a separate issue, closing this issue because it is most likely a DB/Disk error and the only thing we can do about it is improve the error message, but it hasn't happened in so long that it's questionable how much it happens.