[ 
https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620491#comment-14620491
 ] 

Ben Craig commented on THRIFT-3228:
-----------------------------------

A lot of my uses of Thrift involve multiple users of Thrift, mostly unaware of 
each other, all coexisting in the same process.  This includes multiple dlls, 
some of which also use Thrift.  With the function level static, there isn't a 
way to arbitrate between the different clients.  None of the clients know whose 
responsibility it is to initialize everything.

The create and destroy at global scope constraint isn't pleasant either, but at 
least all clients can follow that without coordinating amongst each other.

I have strongly considered taking out the overlapped submission thread from 
TPipe entirely, and making a different transport class just to satisfy my 
waitable pipe needs.  The server class that fully takes advantage of the 
overlapped submission thread isn't even currently public, or something that I 
particularly like at this point.

> Fix TAutoOverlapThread may reference released memory
> ----------------------------------------------------
>
>                 Key: THRIFT-3228
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3228
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.9.2
>            Reporter: Paweł Janicki
>            Priority: Critical
>         Attachments: 
> 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, 
> ConsoleApplication1.cpp
>
>
> A released memory may be referenced by TAutoEverlapThread in case there 
> exists a global instance of TPipeServer or TNamedPipeServer or 
> TAutoOverlapThread in compilation module other than 
> src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp
> TPipeServer on listen() instantiates TNamedPipeServer which instantiates 
> TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static 
> function TOverlappedSubmissionThread::release_instance(). This static 
> functions refers to global variable "TCriticalSection 
> TOverlappedSubmissionThread::instanceGuard_" defined in 
> src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp.
> As the d-tion of globar variable is undefined across compilation modules it 
> may happen that if user defined global variable holding reference to
> TPipeServer, the instanceGuard_ can be freed by CRT before call to 
> TPipeServer d-tor, which will reference deleted global variable 
> instanceGuard_.
> This is because of incorrect implementation of singleton pattern of 
> TOverlappedSubmissionThread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to