[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---------------------------
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There, it
reads an i32 to check the message length. At this step, for some reason, when
the message has been sent with a sync client, it reads {{82 21 01 04}} (the
Thrift header, that contains the protocol version, message type and sequence
id), when it has been sent with an async client, it reads {{00 00 00 09}}
(which is the right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
-I am not sure whether this is an issue on the Rust or Java side (although I
think Rust).- I found [a
topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
on this issue that also has the problem with clients in other languages so it
probably comes from the Rust library. Also I am reporting it on version 0.17.0
because it is the latest available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads {{82 21 01 04}} (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads {{00 00 00 09}} (which is the
right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
> --------------------------------
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
> Affects Versions: 0.17.0
> Reporter: Victor
> Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
