New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not fatal RLPList cast error #518

Closed
zilm13 opened this Issue Sep 14, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@zilm13
Collaborator

zilm13 commented Sep 14, 2016

Getting this error from time to time:

16:26:15.162 INFO [sync]  Success importing BEST: block.number: 1618456, block.hash: d769b9, tx.size: 4 
16:26:15.376 WARN [net]  P2p handling failed
io.netty.handler.codec.DecoderException: java.lang.ClassCastException: org.ethereum.util.RLPItem cannot be cast to org.ethereum.util.RLPList
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99)
    at io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)
    at org.ethereum.net.rlpx.NettyByteToMessageCodec.channelRead(NettyByteToMessageCodec.java:56)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
    at io.netty.handler.timeout.ReadTimeoutHandler.channelRead(ReadTimeoutHandler.java:152)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:110)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassCastException: org.ethereum.util.RLPItem cannot be cast to org.ethereum.util.RLPList
    at org.ethereum.core.Block.parseRLP(Block.java:133)
    at org.ethereum.core.Block.getShortHash(Block.java:445)
    at org.ethereum.net.eth.message.NewBlockMessage.toString(NewBlockMessage.java:81)
    at org.ethereum.net.rlpx.MessageCodec.decodeMessage(MessageCodec.java:139)
    at org.ethereum.net.rlpx.MessageCodec.decode(MessageCodec.java:87)
    at org.ethereum.net.rlpx.MessageCodec.decode(MessageCodec.java:37)
    at io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageCodec.java:81)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
    ... 18 more
16:26:15.395 INFO [facade]  Connecting to: 148.251.220.116:30303
16:26:15.526 INFO [sync]  Success importing BEST: block.number: 1618457, block.hash: ba29f8, tx.size: 2 

rlpEncoded block example:

f90218f90213a0ac2dc49bb952e26c83c53645363319cdeee4e84e41730f7be707d96a7e6ad760a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347944e830b72453be18dfc98cf7b214e6467a84e974aa0b7252ef412fb4eb0a812f22375160382632da30e17d477ddc5f97f4dd605b97ca056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421b9010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000840498f3f583190b4e8347e7c4808457d9553c98d783010500844765746887676f312e362e32856c696e7578a0083af12025be4f382529a238e8340aeece7338c87af88ce6c37526ee574d446288c4469069376a82e180c0

block.get(1) is RLPItem in this case with byte[0] payload

@zilm13 zilm13 added the bug label Sep 14, 2016

@zilm13 zilm13 self-assigned this Sep 14, 2016

@zilm13

This comment has been minimized.

Show comment
Hide comment
@zilm13

zilm13 Sep 15, 2016

Collaborator

@Nashatyrev
I'm not sure that we should do anything with it:

  • message is incorrect, it should have empty list 0xc0, but has0x80 in txTransactions
  • it's not the place of responsibility for RLP decode of message . Maybe this message shouldn't be decoded in the end, who knows it in MessageCodec?
  • error is thrown only when net logger DEBUG is enabled

What do you think?

Collaborator

zilm13 commented Sep 15, 2016

@Nashatyrev
I'm not sure that we should do anything with it:

  • message is incorrect, it should have empty list 0xc0, but has0x80 in txTransactions
  • it's not the place of responsibility for RLP decode of message . Maybe this message shouldn't be decoded in the end, who knows it in MessageCodec?
  • error is thrown only when net logger DEBUG is enabled

What do you think?

@Nashatyrev Nashatyrev added the invalid label Sep 29, 2016

@Nashatyrev

This comment has been minimized.

Show comment
Hide comment
@Nashatyrev

Nashatyrev Sep 29, 2016

Member

That's probably buggy peer implementation. I never saw this error in logs, so let's assume this is just incorrect message encoding. We shouldn't decode it.

Member

Nashatyrev commented Sep 29, 2016

That's probably buggy peer implementation. I never saw this error in logs, so let's assume this is just incorrect message encoding. We shouldn't decode it.

@Nashatyrev Nashatyrev closed this Sep 29, 2016

@cupuyc

This comment has been minimized.

Show comment
Hide comment
@cupuyc

cupuyc Oct 4, 2016

Collaborator

I saw the same exception
https://gist.github.com/cupuyc/5c68e43a6a606d4b545436c01bcdb473

2016-10-04 15:03:19,771 INFO  [SyncQueueThread] sync - Success importing BEST: block.number: 68227, block.hash: e4b5e8, tx.size: 2 
2016-10-04 15:03:19,773 WARN  [EthJClientWorker-4] net - Eth handling failed
java.lang.ClassCastException: org.ethereum.util.RLPItem cannot be cast to org.ethereum.util.RLPList
at org.ethereum.core.Block$Builder.create(Block.java:481)
Collaborator

cupuyc commented Oct 4, 2016

I saw the same exception
https://gist.github.com/cupuyc/5c68e43a6a606d4b545436c01bcdb473

2016-10-04 15:03:19,771 INFO  [SyncQueueThread] sync - Success importing BEST: block.number: 68227, block.hash: e4b5e8, tx.size: 2 
2016-10-04 15:03:19,773 WARN  [EthJClientWorker-4] net - Eth handling failed
java.lang.ClassCastException: org.ethereum.util.RLPItem cannot be cast to org.ethereum.util.RLPList
at org.ethereum.core.Block$Builder.create(Block.java:481)
@zilm13

This comment has been minimized.

Show comment
Hide comment
@zilm13

zilm13 Oct 4, 2016

Collaborator

Catched it again

Peer V62: [ cd661146, BLOCK_RETRIEVING, ping 266 ms, difficulty 69647330660170231275, best block 2379151 ]: Parity/v1.3.2-beta-e298ab3-20160929/x86_64-linux-gnu/rustc1.11.0
Peer V62: [ 3fc9fe13, BLOCK_RETRIEVING, ping 996 ms, difficulty 69658635633309937532, best block 2379281 ]: Parity/v1.3.2-beta/x86_64-linux-gnu/rustc1.11.0

are sending blocks like this (not all, just part among good blocks):
RLP.decode2(new byte [] {-62, -128, -64})

We are getting exception, disconnect, and it doesn't affect reputation of these nodes for us
There are other nodes with the same versions of Parity, and I don't see them in disconnect messages.

@Nashatyrev what do you think? I think we should at least catch it and decrease node's reputation. If node doesn't have block, it shouldn't include it in list, but not sending empty block, yeah?

Collaborator

zilm13 commented Oct 4, 2016

Catched it again

Peer V62: [ cd661146, BLOCK_RETRIEVING, ping 266 ms, difficulty 69647330660170231275, best block 2379151 ]: Parity/v1.3.2-beta-e298ab3-20160929/x86_64-linux-gnu/rustc1.11.0
Peer V62: [ 3fc9fe13, BLOCK_RETRIEVING, ping 996 ms, difficulty 69658635633309937532, best block 2379281 ]: Parity/v1.3.2-beta/x86_64-linux-gnu/rustc1.11.0

are sending blocks like this (not all, just part among good blocks):
RLP.decode2(new byte [] {-62, -128, -64})

We are getting exception, disconnect, and it doesn't affect reputation of these nodes for us
There are other nodes with the same versions of Parity, and I don't see them in disconnect messages.

@Nashatyrev what do you think? I think we should at least catch it and decrease node's reputation. If node doesn't have block, it shouldn't include it in list, but not sending empty block, yeah?

@Nashatyrev

This comment has been minimized.

Show comment
Hide comment
@Nashatyrev

Nashatyrev Oct 4, 2016

Member

@zilm13 Hm interesting question...
Fixed the related bug here:
f5bfece
I.e. Geth nodes just skip non-existing block.
I'm not sure what parity means by {-62, -128, -64}
M.b. it make sense to check with Parity code on this?

Member

Nashatyrev commented Oct 4, 2016

@zilm13 Hm interesting question...
Fixed the related bug here:
f5bfece
I.e. Geth nodes just skip non-existing block.
I'm not sure what parity means by {-62, -128, -64}
M.b. it make sense to check with Parity code on this?

@zilm13

This comment has been minimized.

Show comment
Hide comment
@zilm13

zilm13 Oct 5, 2016

Collaborator

@Nashatyrev
I guess it's no transactions, no uncles BlockBody, but I couldn't find anything from Parity code which could produce such result, at least for a reasonable amount of time.

Both transactions and uncles are vectors, rlp compression is general for all by types. But these guys are doing crazy things like this https://github.com/ethcore/parity/blob/master/util/rlp/src/commonrlps.rs and lots of other optimizations, I don't know Rust and it's not well supported by IDE, so maybe I missed smth.

Collaborator

zilm13 commented Oct 5, 2016

@Nashatyrev
I guess it's no transactions, no uncles BlockBody, but I couldn't find anything from Parity code which could produce such result, at least for a reasonable amount of time.

Both transactions and uncles are vectors, rlp compression is general for all by types. But these guys are doing crazy things like this https://github.com/ethcore/parity/blob/master/util/rlp/src/commonrlps.rs and lots of other optimizations, I don't know Rust and it's not well supported by IDE, so maybe I missed smth.

@Nashatyrev

This comment has been minimized.

Show comment
Hide comment
@Nashatyrev
Member

Nashatyrev commented Oct 27, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment