[jira] [Updated] (THRIFT-3224) Unpredictable behavior of TNamedPipeServer

["Paweł (JIRA)" <ji...@apache.org>]

     [ 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 freed 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()" 

{
    TAutoCrit lock(pipe_protect_);
    GlobalOutput.printf("Client connected.");
    shared_ptr<TPipe> client(new TPipe(Pipe_.h));
    Pipe_.release();
}

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.


> Unpredictable behavior of TNamedPipeServer
> ------------------------------------------
>
>                 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
>   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 freed 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)