After a long debugging session, Marco/Sascha/(Michi?) found out that a static QMenu* in mitk/CoreUI/Qmitk/QmitkRenderWindowMenu.cpp was part of the problem, because in the period when there are two StdMultiWidgets for a short time, concurrent access to this menu and following signal/slot connections lead to a crash.

The solution to this problem is to remove the static QMenu and replace it by "normal" members.

I changed QmitkRenderWindowMenu in a way that it now has Get/SetCrosshairMenu members and that is able to share such a menu across instances. QmitkStdMultiwidget uses the Get/SetCrosshairMenu members to make all of its render windows share a common menu for crosshair options.

After fixing the issue above, a new very related issue arised, which will be solved as part of this bug, too. QmitkStdMultiwidget did not have a destructor so far. This left a at least two listeners to GlobalInteraction registered. GlobalInteraction would then send events to destroyed objects sometimes. This can be solved by adding a destructor to QmitkStdMultiwidget and properly unregistering any observers.

My proposed patch for this issue.

A redisign of the render window menu implementation is proposed in T3187

[SVN revision 20903]
FIX (#3186): preliminary repair of an application crash when closing the multiwidget; redesign of the menu proposed in T3187

reopen for trunk merge

[SVN revision 20904]
FIX (#3186): preliminary repair of an application crash when closing the multiwidget; redesign of the menu proposed in T3187 (merge from 0.14)

Merge to trunk.