[ https://issues.apache.org/jira/browse/THRIFT-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542065#comment-15542065 ]
ASF GitHub Bot commented on THRIFT-3932: ---------------------------------------- Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1103 I made this single change: > +++ b/lib/cpp/test/processor/ProcessorTest.cpp > uint32_t checkNewConnEvents(const boost::shared_ptr<EventLog>& log) { > // Check for an ET_CONN_CREATED event > Event event = log->waitForEvent(2000); // <<< I added "2000" > BOOST_CHECK_EQUAL(EventLog::ET_CONN_CREATED, event.type); After making that change I can run processor_test: > jking@jking-dvm51-buildenv-2:~/thrift-build$ ctest -R processor_test > Test project /home/jking/thrift-build > Start 19: processor_test > 1/1 Test #19: processor_test ................... Passed 33.84 sec > > 100% tests passed, 0 tests failed out of 1 > > Total Test time (real) = 33.88 sec Looks like it's time to re-enable these tests! > C++ ThreadManager has a rare termination race > --------------------------------------------- > > Key: THRIFT-3932 > URL: https://issues.apache.org/jira/browse/THRIFT-3932 > Project: Thrift > Issue Type: Bug > Components: C++ - Library > Reporter: Buğra Gedik > Assignee: James E. King, III > Attachments: thrift-patch > > Time Spent: 8h > Remaining Estimate: 0h > > {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls > {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_ > != workerMaxCount_)}}. Within the {{run}} method of the workers, the last > thread that detects {{workerCount_ == workerMaxCount_}} notifies > {{removeWorker}}. The {{run}} method has the following additional code that > is executed at the very end: > {code} > { > Synchronized s(manager_->workerMonitor_); > manager_->deadWorkers_.insert(this->thread()); > if (notifyManager) { > manager_->workerMonitor_.notify(); > } > } > {code} > This is an independent synchronized block. Now assume 2 threads. One of them > has {{notifyManager=true}} as it detected the {{workerCount_ == > workerMaxCount_}} condition earlier. It is possible that this thread gets to > execute the above code block first, {{ThreadManager}}'s {{removeWorker}} > method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the > object is destructed. When the other thread reaches the synchronized block > above, it will crash, as the manager is not around anymore. > Besides, {{ThreadManager}} never joins its threads. > Attached is a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)