`PooledByteBuf.readBytes` allocates released buffer instead of a writeable one

Expected behavior

ByteBuf.readBytes should not throw an exception because the buffer allocated within the method is already released.

Actual behavior

readBytes when using a PooledByteBufAllocator sometimes (rarely) throws an exception because the buffer allocated inside the method is already released:

io.netty.util.IllegalReferenceCountException: refCnt: 0
  at io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1454)
  at io.netty.buffer.AbstractByteBuf.ensureWritable0(AbstractByteBuf.java:289)
  at io.netty.buffer.AbstractByteBuf.ensureWritable(AbstractByteBuf.java:280)
  at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1103)
  at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:872)
  at eu.cloudnetservice.driver.network.netty.codec.NettyPacketDecoder.decode(NettyPacketDecoder.java:68)

The method newDirectBuffer in PooledByteBufAllocator seems to have a directArea available and allocates a buffer from it (was able to catch it once using a debugger). The buffer returned from that is already released.

Steps to reproduce

As suggested by @chrisvest : “You can try setting io.netty.allocator.smallCacheSize, io.netty.allocator.normalCacheSize, and io.netty.allocator.maxCachedBufferCapacity to 0.”

Then make sure netty is using the PooledByteBufAllocator (for me directByDefault is true) and just try to read bytes of a spcifc length from an incoming buffer (ByteBuf#readBytes(int): ByteBuf)

Sometimes the method will raise an IllegalReferenceCountException when trying to copy the bytes from one buffer to the other.

Minimal yet complete reproducer code (or URL to code)

int length = in.readInt();
ByteBuf body = in.readBytes(length);

Netty version

4.1.77.Final

JVM version (e.g. java -version)

openjdk version “17.0.3” 2022-04-19 OpenJDK Runtime Environment (build 17.0.3+7-Debian-1deb11u1) OpenJDK 64-Bit Server VM (build 17.0.3+7-Debian-1deb11u1, mixed mode, sharing)

OS version (e.g. uname -a)

Linux 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

[derklaro]

Setting the system properties you send me (I mentioned them above) increases the likeliness by a lot

[derklaro]

Should be around 100 - 150. Maybe it is also noteworthy that there are multiple indepent applications running which are all allocating buffers at the same time (the receive the same message around the same time)