Closed veshij closed 1 month ago
@veshij thank you for reporting this issue! It does seem like the situation you mentioned will always arise when w.conn.Write(w.buf[:w.offset])
returns an error and there is more data to write than the buffer capacity.
Are you interested in contributing a PR with the fix that also contains a unit test? If not, I'll pick it up.
I can take a look, not sure how to implement test yet.
Oleg Guba
Чт, 4 июля 2024 г. в 09:33, Arjan Singh Bal @.***>:
Assigned #7389 https://github.com/grpc/grpc-go/issues/7389 to @veshij https://github.com/veshij.
— Reply to this email directly, view it on GitHub https://github.com/grpc/grpc-go/issues/7389#event-13397033814, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOURUMKSH5U4DIJDJDSYYTZKV2NPAVCNFSM6AAAAABKKPZOGOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGM4TOMBTGM4DCNA . You are receiving this because you were assigned.Message ID: @.***>
You can unit test only the bufWriter
struct by passing it a conn that returns an error. Then call buffWriter.Write()
with a sufficiently large buffer. If the test gets stuck in an infinite loop as we suspect in the current state, and returns error with the fix made, I think it should be good enough.
Possible root cause is this change from 6 years ago: https://github.com/grpc/grpc-go/pull/2092
You can unit test only the
bufWriter
struct by passing it a conn that returns an error. Then callbuffWriter.Write()
with a sufficiently large buffer. If the test gets stuck in an infinite loop as we suspect in the current state, and returns error with the fix made, I think it should be good enough.
thank you, working on the PR
Created https://github.com/grpc/grpc-go/pull/7394/files Noticed that bytes written (n) returned in case of an error is incorrect in existing implementation, but probably worth fixing in a separate PR.
This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.
What version of gRPC are you using?
v1.63.2
What version of Go are you using (
go version
)?1.19.9
What operating system (Linux, Windows, …) and version?
Linux
What did you do?
We observed instances of an application with higher-than-expected CPU usage. Upon investigation following profile was collected:
Corresponding stack:
We suspect that under certain conditions the following code might end up in infinite loop:
Conditions to get into infinite loop state:
It seems to be safe to terminate the
for len(b) > 0
cycle on first received error from flushKeepBuffer().