LEAK: ByteBuf.release() was not called before it's garbage-collected

[bing568186255]

when I use grpc-java 1.33.1 ,then an error occured. detail msg as follow

LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 
Created at:
io.grpc.netty.shaded.io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:363)
io.grpc.netty.shaded.io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
io.grpc.netty.shaded.io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
io.grpc.netty.shaded.io.netty.channel.unix.PreferredDirectByteBufAllocator.ioBuffer(PreferredDirectByteBufAllocator.java:53)
io.grpc.netty.shaded.io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)
io.grpc.netty.shaded.io.netty.channel.epoll.EpollRecvByteAllocatorHandle.allocate(EpollRecvByteAllocatorHandle.java:75)
io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:777)
io.grpc.netty.shaded.io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475)
io.grpc.netty.shaded.io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.lang.Thread.run(Thread.java:748)

[temawi]

That release is over three years old, are you able to try it with the latest release and see if you still see this issue?

[bing568186255]

Apr 10, 2024

No, because I have a lot of upstream clients that also rely on grpc 1.33.1, and if I need to push all the other service upgrades, it's too much work. And I looked at the latest 1.62.2 version, and it didn't obviously deal with Bytebuf either

[ejona86]

These errors are generally a bug in your application, but a few have been in gRPC.

If you are using the blocking Iterable stub, there was an issue in gRPC fixed in v1.58.0. If you are configuring retries, there have been a lot of issues fixed (I don't recall if retries were available in 1.33).

For application bugs, I'd suggest checking logs for RejectedExecutionException. Some of these buffers will be freed in Runnables, but if the runnable is rejected it can't be processed/freed. If you are using io.grpc.Detachable, then you can trivially cause a leak, but I doubt you are using Detachable.

There's two cases:

1. This is a bug in your application. Newer gRPC versions provide additional details to track down some of these bugs
2. It is a bug in gRPC. Even if we fix it, you'd have to upgrade to a newer version.

[bing568186255]

这些错误通常是应用程序中的错误，但 gRPC 中也有一些错误。

如果您使用阻塞Iterable存根，则 v1.58.0 中已修复 gRPC 中的问题。如果您正在配置重试，则已经修复了很多问题（我不记得 1.33 中是否提供重试）。

对于应用程序错误，我建议检查日志中是否有 RejectedExecutionException。其中一些缓冲区将在 Runnable 中释放，但如果 R​​unnable 被拒绝，则无法处理/释放它。如果您使用的是io.grpc.Detachable，那么您可能会轻微地导致泄漏，但我怀疑您使用的是 Detachable。

有两种情况：

1. 这是您的应用程序中的一个错误。较新的 gRPC 版本提供了更多详细信息来追踪其中一些错误
2. 这是 gRPC 中的一个错误。即使我们修复了它，您也必须升级到较新的版本。

Thank you for your reply, I try to continue the analysis based on your reply

[ejona86]

Seems like this is resolved as best we can right now, by trying on newer versions of gRPC to see additional information (or see it go away). If you get more details on a newer version, comment, and this can be reopened. Or you can create a new issue.