-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
LEAK: ByteBuf.release() was not called, 1.63.0 #11115
Comments
benjaminp
added a commit
to benjaminp/grpc-java
that referenced
this issue
Apr 19, 2024
`sendGrpcFrame` owns the buffer in `SendGrpcFrameCommand`. If the frame is not handed off to netty, it needs to be released in the method. grpc#11115
larry-safran
pushed a commit
that referenced
this issue
Apr 22, 2024
`sendGrpcFrame` owns the buffer in `SendGrpcFrameCommand`. If the frame is not handed off to netty, it needs to be released in the method. #11115
Fixed by #11116 |
ejona86
pushed a commit
to ejona86/grpc-java
that referenced
this issue
Apr 23, 2024
`sendGrpcFrame` owns the buffer in `SendGrpcFrameCommand`. If the frame is not handed off to netty, it needs to be released in the method. grpc#11115
ejona86
pushed a commit
that referenced
this issue
Apr 25, 2024
`sendGrpcFrame` owns the buffer in `SendGrpcFrameCommand`. If the frame is not handed off to netty, it needs to be released in the method. #11115
3 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of gRPC-Java are you using?
1.63.0
This issue does not occur in version 1.62.2.
What is your environment?
What did you expect to see?
ByteBuf is released
What did you see instead?
LEAK: ByteBuf.release() was not called before it's garbage-collected.
Steps to reproduce the bug
I am implementing a server-streaming RPC using grpc-java with the following behavior:
After the server has been running for a while, the following error occurs:
Speculation
The changes in version 1.63.0 include #10258, which involves modifications in how stream resets are handled. This warning seems to occur in my environment particularly when the client closes the connection first, which may suggest a relationship to these changes.
I suspect the issue may be linked to the handling of closed connections and would appreciate further investigation into whether the changes in PR #10258 could be causing unintended side-effects in byte buffer management.
Others
There is a similar issue reported here: #11084, but it involves a different version and the stack trace is different, so I believe it might be a separate issue.
The text was updated successfully, but these errors were encountered: