[
https://issues.apache.org/jira/browse/THRIFT-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155607#comment-16155607
]
James E. King, III commented on THRIFT-4106:
--------------------------------------------
I found a serious issue hiding in the Pthread implementation which is exposed
by some of the tests. In particular, tests that use detached threads will
typically construct a shared_ptr<Runnable> followed by a shared_ptr<Thread>,
and then make a thread with a thread manager, then call start(). The stack
frame ends so it then destructs the shared_ptr<Thread> and then
shared_ptr<Runnable> however the thread may not have gotten far enough along to
reference the Runnable yet, and you have a race. I am fixing this by ensuring
thread start() does not return until the thread's state is changed to started
by the C style threadMain function. I also was able to run clean with valgrind
for the first time on this test.
> concurrency_test fails randomly
> -------------------------------
>
> Key: THRIFT-4106
> URL: https://issues.apache.org/jira/browse/THRIFT-4106
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.10.0
> Environment: MinGW (appveyor), travis CI
> Reporter: James E. King, III
> Assignee: James E. King, III
> Priority: Critical
>
> While adding Appveyor build support for MinGW (THRIFT-4081), this test failed
> periodically. It would throw an exception in ThreadFactoryTest reapTest
> where it calls monitor.wait(1000). It is reproducible locally as well if you
> have msys2/mingw64 and can use the instructions in the msys2 readme in
> build/cmake. The test has been disabled in mingw appveyor builds for now
> (those builds are new...)
> Travis CI builds are also showing an occasional failure in the test.
> Need to root cause, fix, and re-enable in any CI builds where it was disabled.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)