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