thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King III (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (THRIFT-4405) Incorrect handling of sequence numbers that wrap to negative
Date Thu, 31 Jan 2019 18:39:00 GMT

     [ https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James E. King III updated THRIFT-4405:
--------------------------------------
    Description: 
The following tests were added:

* The cpp client for cross test did not use sequence numbers, so I added a testing protocol
layer for TestClient on top of all protocols that uses a sequence ID that starts at INT32_MAX
- 10, and advances until it wraps around.  This caught a number of negative value handling
issues.
* The cpp client verifies the sequence ID that returns matches what was sent.
* The python client was changed to use pedantic sequence ID checking on all protocols.

The following errors were identified and fixed:

* In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX].
This was changed to allow any 32-bit value, matching other implementations.
* In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing;
this interacted with a bugfix from 2017 (THRIFT-4138) that dropped boost::lexical_cast and
switched to std::stringstream, and this corrupted the negative sequence ID.
* In python, compact protocol, a negative sequence ID was not handled properly because it
is read in and written out as a "var int" which is always positive.

Documentation was added for sequence number handling.

  was:
The following tests were added:

* The cpp client for cross test now uses a sequence ID that starts at INT32_MAX - 10, and
advances until it wraps around.
* The cpp client verifies the sequence ID that returns matches what was sent.
* The python client was changed to use pedantic sequence ID checking on all protocols.

The following errors were identified and fixed:

* In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX].
This was changed to allow any 32-bit value, matching other implementations.
* In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing;
this interacted with a bugfix from 2017 that dropped boost::lexical_cast and switched to std::stringstream,
and this corrupted the negative sequence IDs.
* In python, compact protocol, a negative sequence ID was not handled properly.

Documentation was added for sequence number handling.


> Incorrect handling of sequence numbers that wrap to negative
> ------------------------------------------------------------
>
>                 Key: THRIFT-4405
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4405
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Test Suite
>    Affects Versions: 0.11.0
>         Environment: docker ubuntu-xenial
>            Reporter: James E. King III
>            Assignee: James E. King III
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following tests were added:
> * The cpp client for cross test did not use sequence numbers, so I added a testing protocol
layer for TestClient on top of all protocols that uses a sequence ID that starts at INT32_MAX
- 10, and advances until it wraps around.  This caught a number of negative value handling
issues.
> * The cpp client verifies the sequence ID that returns matches what was sent.
> * The python client was changed to use pedantic sequence ID checking on all protocols.
> The following errors were identified and fixed:
> * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX].
This was changed to allow any 32-bit value, matching other implementations.
> * In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing;
this interacted with a bugfix from 2017 (THRIFT-4138) that dropped boost::lexical_cast and
switched to std::stringstream, and this corrupted the negative sequence ID.
> * In python, compact protocol, a negative sequence ID was not handled properly because
it is read in and written out as a "var int" which is always positive.
> Documentation was added for sequence number handling.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message