The callstack as additional information:

The problem occured in context of selection widgets and may be could be patched for selection widgets in context of T26218.

This assumption was incorrect :(. Even if the widget properly release the node if it is deleted the problem still occures?!?

I tested bit more on which combinations provoke the error:

Actions:

1. Load Image (e.g. brain.nrrd)
2. Open plugin with selection widget (e.g. datastorageviewertest)
3. Select image in selection widget (a: via dialog; b: via selection listner)
4. Close plugin
5. Click "Close Project"
6. Delete data storage "by hand" (select everything end press del)
7. Select a non image (e.g. the plane helper objects.

Summary

Following seems to be the case:

• There is a difference between "Close Project" and delete by hand, that is important to reach the invalid state. What is the difference?
• The selection is important to get into the invalid state, but only a selection via the selection dialog (user pressing the selection widget). Why? What is different when going this execution path?
• The invalid state is still there even if the plugin is closed. So it does not seem to be some inconsistency in the state of the plugin.

@kalali @kislinsk , added you two has you have some experience with at least either rendering/mapper or selection concept. May be you have additional ideas.

OK, I have narrowed it further down.

The crash is only caused if the following preconditions are met:

1. A instance of QmitkNodeSelectionDialog is configured with the data storage
2. The QmitkDataStorageTreeInspector is configured as visible (thus the dialog has a tree inspector instance that also gets the data storage pointer)

So using the widgets e.g. only with the list inspectors active does not leed to any crash.
So the most propable cause is routed in some code touched by the QmitkDataStorageSimpleTreeModel::SetDataStorage...

Found it.

As often with mysterious crashes exchanging a SmartPointer by an mitk::WeakPointer (In this case in the QmitkDataStorageTreeModelInternalItem) helps. :P

Don't ask me why it causes this problems, because everything should be removed. But doing so removes the crashes.

Pushed new branch T26219-Crash_by_selection_widget_after_close_project.

Maybe for further investigation, if something similar or strange happens again:

What I also did was action 1, action 2 action 3a.
Then I removed the selection from the widget (using IsOptional) and continued with action 5 and action 1 -> crash.

What I also did was the same sequence but loading a different image as the last action -> crash

I also added m_SelectedNode = nullptr; inside void QmitkSingleNodeSelectionWidget::OnClearSelection() but that did not change anything.

I got the impression that this has its root somewhere else and not in the selection widget, so I tried the following:

• commented line m_Window->GetActivePage()->CloseEditors(editorsToClose, false); (line 133 in QmitkCloseProjectAction.cpp)
  • that way the render windows will not be closed

Same actions as above -> no crash
Then: I closed the render window manually and did Reinit on the newly loaded image, which leads to the render window being opened again -> crash.

Can you reproduce your problem now with the fix, that helped me out?

Nope

😄