With the modelfit inspector it most often crashed, if the user clicked on a datanode in the datastorage

When I reproduced the issue with MatchPoint, it didn't happen when the documentation was in the background (i.e. the documentation is not the active editor). I guess this is a good starting point for debugging.

I got the same result as kislinsk, the crash only occurs when the documentation is open and not in the background

I tested it in debug mode and the fix is pretty simple. The crashes occurs in lines like GetRenderWindowPart()->RequestUpdate() when GetRenderWindowPart() returns a nullptr. I guess there are quite a few unchecked lines like this in MITK.

The obvious fix is to do a nullptr check and it is done this way in a few places. However, there are more options depending on the situation.

You can pass a strategy parameter to GetRenderWindowPart() (default is NONE). There are also BRING_TO_FRONT, ACTIVATE, and OPEN. For example, BRING_TO_FRONT would already work here but still possibly returns a nullptr if the render editor/view was completely closed. OPEN is the strongest strategy and will even open a render view if there's no such editor/view open.

In case of QmitkMatchPoint::OnRegResultIsAvailable() I think this is a good way as we can assume that opening a render editor/view after the result is available won't disturb but actually help a user to understand what is going on.

- this->GetRenderWindowPart()->RequestUpdate();
+ this->GetRenderWindowPart(mitk::WorkbenchUtil::OPEN)->RequestUpdate();

The whole repository should be searched for unchecked calls to GetRenderWindowPart() to resolve this task.

I will go through the source tree and as a rule of thumb I will just add nullptr checks if the render window part is only used for rendering updates and add the OPEN strategy if more is done with the reference and there is not already a nullptr check.

Since you also mentioned different editors: Not sure if this is also related but one of the terminal outputs of the testers was:

BlueBerry ERROR: Problem detected with part org.blueberry.editors.help(class = berry::HelpEditor): Editor is not firing a PROP_INPUT event in response to IReusableEditor.setInput(...)

But there was no crash in this case.