The serial communications thread in mitkNDITrackingDevice is throwing exceptions that are not handled in ThreadStartTracking. This ends up with a call to terminate() and a crash of the application.
A possible solution is to add a try/catch block in ThreadStartTracking and a std::exception_ptr in mitkNDITrackingDevice so the main thread can access to the exception thrown in the spawned thread context, and the spawned thread exits cleanly its main function.
Thanks for this contributions! It seems there are some open issues regarding exception handling in the NDITrackingDevice.
As far as I can see within the introduced try / catch block the only exception thrown is a mitk::IGTHardwareException in TrackTools() if the returnvalue received via the NDIProtocol is not NDIOKAY. This exception should, in my opinion, also be thrown by the methods TrackMarkerPositions(), and TrackToolsAndMarkers(). Would it then be possible to catch this specific exception?
Also, if an exception is now caught, it is not really handled but only saved in m_ExceptionPtr without notification that something went wrong. At least outputting something to the log would be helpful.
Happy to discuss this in further detail.
Hi. I completely agree with your comment. I just implemented a handler to avoid a call to terminate() in my application, but the implementation is incomplete. The main problem, as you commented,, is how are we going to let know the main thread that an exception occurred in the tracking thread. There are several possibilities (it would be great to have Qt signals mechanism here), but I think that we have two main options:
Let's keep the discussion rolling because I still do not see a clear and nice solution.
Hi there! 🙂
This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑
Best wishes,
The MITK devs