[ https://issues.apache.org/jira/browse/THRIFT-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030486#comment-14030486 ]
Grzegorz Leszczyński commented on THRIFT-2521: ---------------------------------------------- Sorry, but I will not think about this test, because I'm not sure if it is possible and moreover I don't have time for this. We applied this patch in our company and I just want to help and share it with you. It's up to you, what happens with this patch :-) I can say in two words what was the main problem (except some missing locks and unused params and variables). When we are stopping ThreadManager all workers need to stop. When last of them decreases workerCount_ to 0 in ThreadManager::Worker::run and calls workerMonitor_.notify(), then ThreadManager::Impl::removeWorker called from ThreadManager::Impl::stopImpl passes through "while (workerCount_ != workerMaxCount_) { workerMonitor_.wait(); }" and ThreadManager gets destroyed. But at this moment other workers can be in ThreadManager::Worker::run somewhere between "manager_->workerCount_--;" and "Synchronized s(manager_->workerMonitor_);" and when they get processor they cause crash, because ThreadManager is already destroyed. > Fixed synchronisation in ThreadManager.cpp > ------------------------------------------ > > Key: THRIFT-2521 > URL: https://issues.apache.org/jira/browse/THRIFT-2521 > Project: Thrift > Issue Type: Bug > Components: C++ - Library > Affects Versions: 0.9.2, 1.0 > Reporter: Grzegorz Leszczyński > Labels: patch > Fix For: 0.9.2, 1.0 > > Attachments: thrift-2521-ThreadManager.patch > > > Server can crash, when stop is called. Fixes also other minor synchronisation > problems. -- This message was sent by Atlassian JIRA (v6.2#6252)