[
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)
