Weak error handling in ByteToMessageDecoder?
See original GitHub issueI have this stack trace from 4.1.32 for a leak report, but the code is not significantly changed in this area in 4.1.43 as far as I can see.
io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:331)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:185)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:176)
io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:113)
io.netty.handler.codec.ByteToMessageDecoder.expandCumulation(ByteToMessageDecoder.java:529)
io.netty.handler.codec.ByteToMessageDecoder$1.cumulate(ByteToMessageDecoder.java:89)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:656)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:591)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:508)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:470)
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
java.lang.Thread.run(Thread.java:748)
org.neo4j.helpers.NamedThreadFactory$2.run(NamedThreadFactory.java:122
My contention is that the error handling is weak around expandCumulation
because for example:
static ByteBuf expandCumulation(ByteBufAllocator alloc, ByteBuf cumulation, int readable) {
ByteBuf oldCumulation = cumulation;
cumulation = alloc.buffer(oldCumulation.readableBytes() + readable);
cumulation.writeBytes(oldCumulation);
oldCumulation.release();
return cumulation;
}
if this fails after alloc.buffer
then that buffer gets completely lost. Even up the stack in ByteToMessageDecoder$1.cumulate
(MERGE_CUMULATOR) if writeBytes fails then the returned buffer gets lost.
Thoughts?
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Handling exception in ByteToMessageDecoder - Stack Overflow
When I throw an exception, it is catched in the following handler which will just log it and close the connection. And I...
Read more >Improper Error Handling - OWASP Foundation
Improper handling of errors can introduce a variety of security problems for a web site. The most common problem is when detailed internal...
Read more >ByteToMessageDecoder (Netty API Reference (4.1.85.Final))
Gets called after the ByteToMessageDecoder was removed from the actual context and it doesn't handle events anymore. Throws: Exception. channelRead. public void ...
Read more >Error Handling Flaws - Information and How to Fix - Veracode
Improper error handling flaws occur when an error message that's displayed to an end user provides clues about how an application or website...
Read more >Poor Error Handling: Return Inside Finally - Fortify Taxonomy
The second is producing errors that either give out too much information (to possible attackers) or are difficult to handle. Poor Error Handling:...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@njhill @normanmaurer Thanks for confirming the issue. I’ll attempt a PR shortly!
Thank you both for the review and acceptance!