[
https://issues.apache.org/jira/browse/THRIFT-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211145#comment-15211145
]
Ted Wang commented on THRIFT-3238:
----------------------------------
There may be multiple places that would require patching or some consideration.
I probably tunneled in on the one specific race that I was seeing, so my fix
may not be sufficient. I'll just explain the issue that I was seeing here for
future references, and to show that it won't be covered with the patch in
initiateNamedConnect.
The race that I saw was that the client disconnects before TPipeServer was
about to construct the TPipe to hand back from accept:
https://github.com/apache/thrift/blob/4733db4e151794a7a6e1cbbb5396e5d1146f1f8e/lib/cpp/src/thrift/transport/TPipeServer.cpp#L292
So what happens when TPipeServer constructs a TPipe when the client has already
disconnected? It turns out that TPipe calls beginAsyncRead in the constructor,
which gets an error from submitting readOverlap_, if it was immediately
processed, and throws TTransportException::UNKNOWN.
https://github.com/apache/thrift/blob/4733db4e151794a7a6e1cbbb5396e5d1146f1f8e/lib/cpp/src/thrift/transport/TPipe.cpp#L108
Because the exception type is UNKNOWN, TServerFramework::serve hits the else
case here and simply exits:
https://github.com/apache/thrift/blob/4733db4e151794a7a6e1cbbb5396e5d1146f1f8e/lib/cpp/src/thrift/server/TServerFramework.cpp#L177
> Fix TNamedPipeServer can be interrupted by faulty client
> --------------------------------------------------------
>
> Key: THRIFT-3238
> URL: https://issues.apache.org/jira/browse/THRIFT-3238
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.2
> Environment: Windows
> Reporter: Paweł Janicki
> Priority: Critical
> Attachments:
> 0001-Fix-TNamedPipeServer-can-be-interrupted-by-faulty-cl.patch,
> 0002-THRIFT-3238.-cpp-Fix-TNamedPipeServer-can-be-interru.patch
>
>
> A faulty or hostile client can cause TNamedPipeServer to be interrupted and
> return from serve(). The client that causes such effect just needs to open
> and immediately close TPipe transport.
> Caused by not handling some NamedPipe error codes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
