During work on D512 I encountered multiple seemingly random crashes with incompatible vector iterators within mitk::TimeGeometry::UpdateBoundingBox(). An experimental fix was done by introducing a mutex lock_guard in front of anything not thread-safe within that method (m_BoundingBox->SetPoints(points); and m_BoundingBox->ComputeBoundingBox();). This solved the problem, so it seems the cause was a racing condition between multiple calls to UpdateBoundingBox(). However, simply blocking with a mutex might increase runtime, the degree of this was not checked (although it was not directly noticeable in my case).
It would be good to take a look at this and see if there is another way to make this method thread-safe, or if a mutex is the best solution.
Description
Event Timeline
Question to discuss: Should we invistigate it further or reactivate if there is realy a performance problem evident?
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
Discussion result: we'll keep the task open. When eMITK builds again for the current state, try to reproduce the crash by going through the Geldosimetry workflow.
If it can't be reproduced, close the task.
If it can be reproduced, depending on the way the error expresses itself, either fix or accept as is.
This task was closed here on Phabricator since it was migrated to GitLab. Please continue on GitLab.