[
https://issues.apache.org/jira/browse/THRIFT-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632995#comment-13632995
]
Martin Michelsen commented on THRIFT-1931:
------------------------------------------
Hi Randy,
I agree that that's the expected behavior (disconnecting the client) but the
assertion failure seems like an actual issue. I'm not intimately familiar with
the style and conventions used in Thrift, but at least in my own work, an
assertion failure means that either (1) there's a bug in my code somewhere
which is causing the program to get into a state I didn't expect it to be in,
or (2) the assertion condition is invalid and should be changed or removed. In
this case, the assertion leads to very different behavior with and without
NDEBUG. I think it makes sense that invalid frame sizes should be handled the
same way as frame sizes that are too large rather than running through an
unexpected state (even if it gives the right result), but this is only my
intuition.
Anyway, I'll use NDEBUG for now to avoid this issue. Thanks!
~ Martin
> 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
