Bug: When use gzip and call with MaxCallRecvMsgSize(math.MaxInt64), will read 0 byte.

[catundercar]

NOTE: if you are reporting is a potential security vulnerability or a crash,
please follow our CVE process at
https://github.com/grpc/proposal/blob/master/P4-grpc-cve-process.md instead of
filing an issue here.

Please see the FAQ in our main README.md, then answer the questions below
before submitting your issue.

What version of gRPC are you using?

master

What version of Go are you using (go version)?

1.19.2

What operating system (Linux, Windows, …) and version?

Linux

What did you do?

If possible, provide a recipe for reproducing the error.
like this demo:
https://github.com/grpc/grpc-go/tree/master/examples/features/compression
I called with grpc.MaxCallRecvMsgSize(math.MaxInt64)
And then, I got this result:

UnaryEcho call returned "", <nil>

The response message was "".

What did you expect to see?

UnaryEcho call returned "compress", <nil>

[dfawley]

I called with grpc.MaxCallRecvMsgSize(math.MaxInt64)

This is definitely wrong. The most you'd ever want to do is math.MaxInt. And even that is a pretty insane maximum. The intent of this setting is to protect you from running out of memory. No machine has 9,223,372,036,854,775,807 bytes of memory.

[catundercar]

I called with grpc.MaxCallRecvMsgSize(math.MaxInt64)

This is definitely wrong. The most you'd ever want to do is math.MaxInt. And even that is a pretty insane maximum. The intent of this setting is to protect you from running out of memory. No machine has 9,223,372,036,854,775,807 bytes of memory.

You're right, in actual business scenarios, the received data will never reach math.MaxInt. But that's not the key of this issue. Perhaps I didn't describe it clearly enough. The key of this issue is that when using the gzip compressor and configuring grpc.MaxCallRecvMsgSize(math.MaxInt), no matter how small the actual data is, even if it's only one byte, the logic in the decompressor will overflow, causing no data to be read.

I want to emphasize a point that the original available configuration of grpc.MaxCallRecvMsgSize(math.MaxInt) causes the service to not return any valid messages and there is no error reported during the call, when combined with the gzip compression method. It should be a problem that needs to be fixed, rather than asking the user to modify their previously available code.
Looking forward to your reply.

[dfawley]

As mentioned in the PR, this could be fixed by limiting the allowable values in MaxCallRecvMsgSize to math.MaxInt64-1. The PR as submitted is incorrect, as we need to be able to read beyond the configured limit to determine whether there was an overrun.

[catundercar]

Yes, it is possible to know if the limit is exceeded without reading out all the bytes. Now it looks like there is no better way to do this than to change the MaxCallRecvMsgSize parameter.😥

[catundercar]

Sorry, I recently discovered that it has been reactivated. Do you have any suitable ways to fix this issue?

[purnesh42H]

@catundercar are you interested in continuing to work on this?

[catundercar]

@catundercar are you interested in continuing to work on this?

Yep, but I have no good idea. 😂

[github-actions]

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.

[infovivek2020]

@purnesh42H please assign me this issue

[infovivek2020]

@purnesh42H while repro getting the as expected response (UnaryEcho call returned "compress", )

[infovivek2020]

@purnesh42H have a look to the PR [https://github.com/infovivek2020/pull/2] I am able to repro in local

[infovivek2020]

@purnesh42H Please have a look to the PR on applied change https://github.com/grpc/grpc-go/issues/4552 we do not have this issue

[purnesh42H]

@infovivek2020 please confirm if this issue is a duplicate of #4552

[infovivek2020]

This issue is duplicate one, it is resolved by PR https://github.com/grpc/grpc-go/issues/4552

[easwars]

Closing this issue as this is marked as a duplicate of #4552