[
https://issues.apache.org/jira/browse/THRIFT-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paweł updated THRIFT-3224:
--------------------------
Description:
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()"
{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.
was:
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()"
{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 freed of the handle value was not performed on a resource that was
opened in meantime by other thread.
> 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ł
> 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()"
> {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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
