[ 
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875376#comment-17875376
 ] 

Victor commented on THRIFT-5812:
--------------------------------

This was the issue indeed. See 
[0dc184d|[https://github.com/victorbnl/thrift-rs-capacity-overflow/commit/0dc184d58eec5ec2e4820fc8c7fcf6615d26cc16]]
 for the fix.

Your proposal looks good! Depending on its ETA, maybe a temporary fix should be 
worked on? Could the server display an error when the wrong transport is used, 
like it does when the wrong Thrift version is? If that looks feasible, I might 
give it a try later.

> 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, 0.20.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.- 
> The issue also occurs when using the latest 0.21.0 Rust library (commit 
> e98d6b1).
> 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)

Reply via email to