Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
0.1
-
None
-
Mac OS X 10.5.6, Xcode
-
Patch Available
Description
The ThreadManagerTests::blockTest() method and its associated ThreadManagerTests::BlockTask class have errors and race conditions that cause frequent failures in the test. Some failure modes return to the caller, but others just hang the test forever. The main problem is that the test function relies on indirect indications that its tasks have reached certain known conditions. The indications that it sees are actually caused by the ThreadManager's Workers, and this results in a number of race conditions between the test function and the BlockTasks.
There are 2 patch files attached. One patches the ThreadManagerTests.h file to fix the test. The other patches Tests.cpp so that it will run the blockTest in a loop. In my experience, an unpatched version of ThreadManagerTests.h generally fails within 100 iterations. After being patched, the test will still fail unless a separate patch is applied to the ThreadManager.cpp file. That patch is part of another issue that I haven't entered yet (because it needs to refer to this one). When I know its number I will add a comment. Anyway, if the patch is applied to ThreadManagerTests.h, but not to ThreadManager.cpp, then the test will still fail, generally with an assert, but sometimes with a Bus Error.
Test Procedure:
1) Apply the Tests.cpp patch. This makes the thread-manager portion of the test run ONLY the blockTest in an effectively infinite loop.
2) Run a make in lib/cpp in order to rebuild concurrency-test
3) Run concurrency test with the command line argument "thread-manager". This will start the blockTest loop. It should fail in a fairly short time. Repeated runs may fail different ways, including infinite hangs.
4) Apply the patch to ThreadManagerTests.h.
5) Run make in lib/cpp to rebuild concurrency-test
6) Run concurrency_test as before. It should probably run for a longer period of time. I have seen it run for an hour or more after beng patched. Eventually it should fail either with an assert in Monitor.cpp while trying to destroy a pthread_mutex_t, or it will get a Bus Error because it tried to execute invalid memory. I have also seen it hang forever.
In order to resolve the remaining issues, a patch needs to be applied to ThreadManager.cpp. I will add a comment about that as soon as the issue is filed and the patch is available.
Attachments
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- is depended upon by
-
-
- Closed
-
- relates to
-
-
- Closed
-