Page MenuHomePhabricator | MITK

Unhandled exception in mitkNDITrackingDevice::ThreadStartTracking
Open, LowPublic

Description

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.

PR: https://github.com/MITK/MITK/pull/229

Event Timeline

milano created this task.Thu, Feb 7, 4:44 PM
milano triaged this task as Low priority.
milano updated the task description. (Show Details)
milano updated the task description. (Show Details)Thu, Feb 7, 9:02 PM

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:

  1. We poll from the main thread a status variable
  1. We pass an error function (std::function maybe) to the tracking thread and the tracking thread calls that function when the exception is catched.

Let's keep the discussion rolling because I still do not see a clear and nice solution.