[
https://issues.apache.org/jira/browse/THRIFT-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617829#comment-14617829
]
ASF GitHub Bot commented on THRIFT-3224:
----------------------------------------
GitHub user ben-craig opened a pull request:
https://github.com/apache/thrift/pull/544
THRIFT-3224 Fix TNamedPipeServer unpredictable behavior on accept
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ben-craig/thrift THRIFT-3224
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/544.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #544
----
commit 1b73af1a4f59e2c85127a70d537712f130329462
Author: Ben Craig <[email protected]>
Date: 2015-07-08T01:54:50Z
Fixing double pipe close
----
> Fix TNamedPipeServer unpredictable behavior on accept
> -----------------------------------------------------
>
> Key: THRIFT-3224
> URL: https://issues.apache.org/jira/browse/THRIFT-3224
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.2
> Environment: Windows
> Reporter: Paweł Janicki
> Assignee: Paweł Janicki
> Priority: Critical
> Labels: patch
> Attachments:
> 0001-THRIFT-3224.-cpp-Fix-TNamedPipeServer-unpredictable-.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Application bahavior utilizing TNamedPipeServer is unpredictable due misuse
> of TAutoHandle.
> Project uses TAutoHandle class, an analogy of std::unique_ptr, for managing
> WIN32 handles. The dangerous members of this concept are: the direct getter
> "HANDLE TAutoHandle::h" and release method "void __thiscall
> TAutoHandle::release()"
> Below code citation introduces serous bug:
> {code:java}
> {
> TAutoCrit lock(pipe_protect_);
> GlobalOutput.printf("Client connected.");
> shared_ptr<TPipe> client(new TPipe(Pipe_.h));
> Pipe_.release();
> }
> {code}
> The getter is used in TNamedPipeServer::acceptImpl() to pass internal
> handle value to c-tor of TPipe and just after c-tion HANDLE__thiscall
> TAutoHandle::release() is called to release ownership. That means the TPipe
> object is expected to take ownership of the resource, but if TPipe c-tor
> throws the d-tor of TAutoHandle is called releasing the resource and the
> incomplete TPipe object does the same. Since now it is impossible to ensure
> that the second free of the handle value was not performed on a resource that
> was opened in meantime by other thread.
> I propose to solve the issue by ensuring the handle is not owned by two
> objects at a time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
