Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Panic on invalid back-reference. #8678

Closed
levirak opened this issue May 21, 2018 · 1 comment · Fixed by #8683
Closed

Panic on invalid back-reference. #8678

levirak opened this issue May 21, 2018 · 1 comment · Fixed by #8683
Assignees
Labels
F1-panic 🔨 The client panics and exits without proper error handling. M4-core ⛓ Core client code / Rust. P2-asap 🌊 No need to stop dead in your tracks, however issue should be addressed as soon as possible.
Milestone

Comments

@levirak
Copy link

levirak commented May 21, 2018

I'm running:

  • Which Parity version?: v1.10.3-stable-b9ceda38a-20180507
  • Which operating system?: Linux (Arch Linux)
  • How installed?: via pacman (local package manager, main repository)
  • Are you fully synchronized?: yes
  • Which network are you connected to?: ethereum
  • Did you try to restart the node?: yes

In the process of using Web3 to inspect the Ethereum main chain, I feed the Parity light client an RPC call that crashed it. Specifically, I asked for for the block 0x1784ac (full hash given below), which is as an uncle of 0x248fe7. Asking for 0x248fe7 successfully returns the block, including any requests for an arbitrary depth of ancestors.

My naive assessment of the situation is that because I am running a light client, the requested block was not recorded on my machine, leading to a chain of events which caused the client to panic. I propose this with a high degree of confidence, as this event only occurred after I first asked for an uncle block while asking for main-chain blocks continues to work.

I presume that the correct behavior would be to either retrieve the block from the Ethereum network or answer with some standard "no such block" kind of RPC response. What follows is the complete transcript of the event for the Parity client:

$ parity --light
2018-05-21 16:10:43  Starting Parity/v1.10.3-stable-b9ceda38a-20180507/x86_64-linux-gnu/rustc1.25.0
2018-05-21 16:10:43  Keys path /home/levi/.local/share/io.parity.ethereum/keys/Foundation
2018-05-21 16:10:43  DB path /home/levi/.local/share/io.parity.ethereum/chains/ethereum/db/906a34e69aec8c0d
2018-05-21 16:10:43  Path to dapps /home/levi/.local/share/io.parity.ethereum/dapps
2018-05-21 16:10:43  Running in experimental Light Client mode.
2018-05-21 16:10:44  Removed existing file '/home/levi/.local/share/io.parity.ethereum/jsonrpc.ipc'.
2018-05-21 16:10:49  Public node URL: [REDACTED]

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

stack backtrace:
   0:     0x56248f3ed93c - <unknown>
   1:     0x56248f3ec1f2 - <unknown>
   2:     0x56248ea357cb - <unknown>

Thread '<unnamed>' panicked at 'Fails only on invalid back-references; back-references here known to be valid; qed: NoSuchOutput', libcore/result.rs:945

This is a bug. Please report it at:

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

Aborted (core dumped)

Steps to reproduce:

The following steps reliably allow me to reproduce the above error.

First, start Parity as such:

$ parity --light

Second, via NodeJS, ask for 0x1784ac:

$ node
> const Web3 = require('web3');
> var web3 = new Web3(new Web3.providers.HttpProvider('http://localhost:8545'));
> web3.eth.getBlock('0x1784ac7715ffe762a730f1dc07aca04138f0a028422b89d700e38717de5fa4bb')

The result is the following error on Node's end:

Error: Invalid JSON RPC response: undefined
    at Object.InvalidResponse (/home/levi/Desktop/test/node.js/node_modules/web3/lib/web3/errors.js:38:16)
    at HttpProvider.send (/home/levi/Desktop/test/node.js/node_modules/web3/lib/web3/httpprovider.js:101:18)
    at RequestManager.send (/home/levi/Desktop/test/node.js/node_modules/web3/lib/web3/requestmanager.js:58:32)
    at Eth.send [as getBlock] (/home/levi/Desktop/test/node.js/node_modules/web3/lib/web3/method.js:145:58)

At this time the instance of Parity has crashed with the previously given output.

@dvdplm
Copy link
Collaborator

dvdplm commented May 22, 2018

Confirmed. The panic comes from here. Investigating.

@dvdplm dvdplm added the F1-panic 🔨 The client panics and exits without proper error handling. label May 22, 2018
@dvdplm dvdplm self-assigned this May 22, 2018
@5chdn 5chdn added this to the 1.12 milestone May 22, 2018
@5chdn 5chdn added P2-asap 🌊 No need to stop dead in your tracks, however issue should be addressed as soon as possible. M4-core ⛓ Core client code / Rust. labels May 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F1-panic 🔨 The client panics and exits without proper error handling. M4-core ⛓ Core client code / Rust. P2-asap 🌊 No need to stop dead in your tracks, however issue should be addressed as soon as possible.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants