It seems to be an observer problem. The segmentation fault gets reported from itk::Command::Execute ( l.257 ) somehow in connection with the SliceNavigationController

It is not the observer. By comparison to the behaviour of the ExtApp we found following difference:

In the ExtApp, the call-stack is the following:

0 QmitkImageNavigatorView::RenderWindowPartDeactivated [143]
1 QmitkViewCoordinator::RenderWindowPartDeactivated [194]
2 QmitkViewCoordinator::PartHidden [149]
3 berry::MessageDelegate1<berry::IPartListener, berry::SmartPointer<berry::IWorkbenchPartReference>, void>::Execute [193]
...
7 berry::PartService::FirePartHidden [71]

In mitkDiffusion, the QmitkImageNavigatorView::RenderWindowPartDeactivated() is not reached at all after QmitkCloseProject::Run() because of QmitkViewCoordinator::PartHidden() is also not reached.

The point of divergence between ExtApp and the mitkDiffusion application is

QmitkCommonActivator::start(ctkPluginContext *context)

where the mitkDiffusion fails the condition

if(berry::PlatformUI::IsWorkbenchRunning())
{
  m_ViewCoordinator = QmitkViewCoordinator::Pointer(new QmitkViewCoordinator);
  m_ViewCoordinator->Start();
}

therefore the ViewCoordinator is not started, i.e. is not listening to the workbench.

Failing to pass the condition IsWorkbenchRunning in the QmitkCommonActivator also explains the log message "BlueBerry Workbench not running" appearing after the start.

As soon as the application reaches the QmitkCommonLegacyActivator, the workbench is then running and hence the IsWorkbenchRunning condition is evaluated to true leading to the log message "BlueBerry Workbench ready".

You should check if there are plug-in dependencies of one of your "eagerly" started plug-ins to org.mitk.gui.qt.common (direct or indirect dependencies). If that is the case, the org.mitk.gui.qt.common plug-in will be started before the Workbench is ready.

That is indeed the case.

Excerpt from org.mitk.diffusionimaging's manifest_headers.cmake
set(Require-Plugin org.mitk.gui.common)
set(Plugin-ActivationPolicy eager)

Hm, I think the interesting plug-in is org.mitk.gui.qt.common (with the "qt") containing the QmitkViewCoordinator class.

You should try to identify the responsible action for starting the org.mitk.gui.qt.common plug-in. Put a break-point in its start() methods and post the full stack strace please.

Complete callstack from start to QmitkViewCoordinator::start() call

Okay, I actually meant the call stack for your diffusion application, where the org.mitk.gui.qt.common activator seems to be called too early (before the workbench is up and running).

Diffusion App callstack to QmitkCommonActivator::start()

The difference is in the berryStarter::Run

-> the mitkDiffusion application reaches the CommonActivator after the call at line 104 : app = runs.front()->CreateExecutableExtension<IApplication> ("class");

-> the ExtApp reaches the end of the ::Run() method and
line 168 : returnCode = app->Start();

gets executed.

The call
plugin->start(ctkPlugin::START_TRANSIENT);
in
berryIConfigurationElement.h
will start the QmitkCommonActivator for mitkDiffusion but not for the ExtApp.

Could possibly the fact, that the diffusionimagingapp has an Intro part, which is derived from berryQtIntroPart.h, be a reason for this behaviour?

Semms my guess was wrong, I removed the welcomeview and appintro files and the problem persists.

I managed to get the Workbench to be ready in time.

The last thing I did, which might be responsible for the whole problem is:
Change
set(Require-Plugin org.mitk.gui.qt.ext org.mitk.gui.qt.stdmultiwidgeteditor)
to
set(Require-Plugin org.mitk.gui.qt.ext )

in the manifest_headers.cmake of the diffusionimagingapp

As this was a last change in a series of changes I will attach a change with all of the changes included.

All changes patch

[def584]: Merge branch 'bug-11715-fix-lifecycle-caused-crashes'

Merged commits:

2012-04-27 12:13:34 Caspar Goch [f9b138]
Removed stdmultiwidgeteditor dependence

(In reply to comment #15)

I managed to get the Workbench to be ready in time.

The last thing I did, which might be responsible for the whole problem is:
Change
set(Require-Plugin org.mitk.gui.qt.ext org.mitk.gui.qt.stdmultiwidgeteditor)
to
set(Require-Plugin org.mitk.gui.qt.ext )

That is it! Well done ;-)