mitkTrackingDeviceSourceTest runs into a timeout in Linux. See
http://mbits/cdash/testSummary.php?project=3&name=mitkTrackingDeviceSourceTest&date=2009-07-22
Therefore the test is currently deactivated in files.cmake.
Someone with a debugging enabled linux environment, please investigate and fix the cause of the timeout.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T1777 unit tests for navigation pipeline base classes | ||
| Resolved | None | T2323 Fix mitkTrackingDeviceSourceTest |
Successfully tested it on a linux VM with the changes committed to T1774. mySource->StartTracking() had to be called to unlock m_TrackingFinishedMutex which is locked in mitkTrackingDevice::StopTracking() called by the destructor of mitkTrackingDeviceSource.
Test still fails on mbits (Dashboard).
maybe the behavior of the class (destructor) should be changed, not the test itself. It could happen, that a pipeline is build but then deleted before StartTracking() is called. This is a valid testcase.
[SVN revision 20892]
FIX (#2323): added check if tracking device is already tracking or is connected before calling StopTracking() or Disconnect() in the destructor of mitkTrackingDeviceSource
What is the status of this? Is this only VM relevant? IT blocks a release critical bug.
[SVN revision 21472]
FIX (#2323): Mutex was left locked when a error occurs in the try section.
[SVN revision 22215]
FIX (#2323): Mutex was locked during thread destruction. For this reason, the thread could not be succesfully terminated and hanged on the lock. This happened when StopTracking() was called before m_TrackingFinishedMutex was locked in TrackTools(). Since StopTracking() also locks m_TrackingFinishedMutex, TrackTools() hangs in there for ever. We changed TrackTools(), so it only locks m_TrackingFinishedMutex if StopTracking() was not previously executed.
[SVN revision 22360]
ENH (#2323): add new test cases for unit mitkTrackingDeviceSourceTest