[
https://issues.apache.org/jira/browse/THRIFT-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632566#comment-13632566
]
Randy Abernethy commented on THRIFT-1931:
-----------------------------------------
Hi Martin,
I would be inclined to hang up on a client sending a frame size <= 0 or > some
max frame. In my experience this type of issue is hard to recover from without
establishing a new connection due to the criticality of frame alignment. The
production code path for this server will close the connection in response to a
client sending a 0 frame size (though you have to test it or walk through the
code a bit to see it), which I think is what you want.
The debug assert here is probably appropriate, interrupting at the moment the
problem is identified in debug builds. Configure sets up Thrift to build
without the no-debug flag by default, leaving the asserts live. If you define
NDEBUG during the build all of the asserts will be removed and you will get the
desired close behavior without the abort. To set the NDEBUG flag try this:
./configure CPPFLAGS='-DNDEBUG'
Then make and install as usual. The wiki describes this a bit here:
http://wiki.apache.org/thrift/ThriftInstallation
Regards,
Randy
> Sending a frame size of zero to a TNonblockingServer causes an assertion
> failure
> --------------------------------------------------------------------------------
>
> Key: THRIFT-1931
> URL: https://issues.apache.org/jira/browse/THRIFT-1931
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9
> Environment: Ubuntu 10.04 and 12.04, both 64-bit
> Reporter: Martin Michelsen
> Labels: TNonblockingServer
>
> TNonblockingServer::TConnection::workSocket doesn't check if readWant_ is
> zero before returning. Sending a frame with a size of zero leads to an
> assertion failure:
> {{src/thrift/server/TNonblockingServer.cpp:494: void
> apache::thrift::server::TNonblockingServer::TConnection::workSocket():
> Assertion `readBufferPos_ < readWant_' failed.}}
> (You can reproduce this behavior on a TNonblockingServer by doing {{echo -e
> '\0\0\0\0' | nc server port}}.)
> It can probably be fixed by checking if readWant_ is zero before the
> transition() call in workSocket, and disconnecting the client if so (just
> like what happens if readWant_ is too large). Not sure if this is necessarily
> the right thing to do though.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
