[
https://issues.apache.org/jira/browse/THRIFT-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15248464#comment-15248464
]
James E. King, III commented on THRIFT-3233:
--------------------------------------------
There are already some fixes in the pull request for THRIFT-3768 because I
found that when I enhanced the TServerIntegrationTest it was exposing the issue
in this defect. Please give those changes a try and see if it resolves the
issues you were seeing.
Note that ThreadManager needs an overhaul. It has three monitors, two of which
are being used to protect the same variables. I'd prefer to implement
something using boost::thread_group at some point because it's going to be more
reliable.
> Fix C++ ThreadManager::Impl::removeWorker worker join
> -----------------------------------------------------
>
> Key: THRIFT-3233
> URL: https://issues.apache.org/jira/browse/THRIFT-3233
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.2
> Reporter: Paweł Janicki
> Assignee: James E. King, III
> Priority: Critical
> Attachments:
> 0001-THRIFT-3233.-cpp-Fix-ThreadManager-Impl-removeWorker.patch
>
>
> ThreadManager::Impl::removeWorker is not joining worker properly.
> It possible that the not joined worker will continue to reference destructed
> ThreadManager's non-static members causing crash.
> It is caused by removeWorker() implementation which waits for workers to
> decrement the ThreadManager's workerCount_. Once value is decremented
> removeWorker() assumes the worker thread joined, while in fact the worker
> thread continues to execute some more code which adds the worker thread to
> destruction list which list may be just freed due to ThreadManager object
> destruction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
