We have registered a custom STL reader that converts an stl file in a different data format than mitk::Surface.
The MitkIGTTrackingToolbox plugin expects though that when a stl file that is kept as a ressource will be read into an mitk::Surface format. In mitkTrackingVolumeGenerator line 92ff a dynamic_cast onto mitk::Surface is used but then the result is not checked against nullptr.
This leads to a seg fault when accessing <cast_result>->GetVtkPolyData().
Solution is a quick check on nullptr and in case of a non surface object delivering an empty new VtkPolyData with an appropriate error message.
Code snippet modified with solution:
*begin snippet*
// from here on, we assume that filename contains an actual filename and not a magic string us::Module* module = us::GetModuleContext()->GetModule(); us::ModuleResource moduleResource = module->GetResource(filename); std::vector<mitk::BaseData::Pointer> data = mitk::IOUtil::Load(moduleResource); if(data.empty()) MITK_ERROR << "Exception while reading file: " << moduleResource.GetResourcePath(); mitk::Surface::Pointer fileoutput = dynamic_cast<mitk::Surface*>(data[0].GetPointer()); if (fileoutput == nullptr) { MITK_ERROR << "Exception while casting data loaded from file: " << moduleResource.GetResourcePath(); output->SetVtkPolyData(vtkSmartPointer<vtkPolyData>(vtkPolyData::New())); } else { output->SetVtkPolyData(fileoutput->GetVtkPolyData()); }
*end snippet*
I still need to clarify how I can adjust our proprietary stl reader to not read that ressource but to let the mitkSurfaceStlIO class read it. This is a bit more difficult as this reader doesn't set its read and write ranking. But I will check.
Set to minor as only a few users probably use a custom stl reader.