Page MenuHomePhabricator

Workbench doesn't start on a few workstations
Closed, ResolvedPublic

Assigned To
Authored By
Aug 9 2016, 5:43 PM
Referenced Files
F3648: happy.gif
Sep 2 2016, 12:12 PM
F1980: disappointed.webm
Aug 16 2016, 1:13 PM
F1743: thankyou.webm
Aug 9 2016, 5:43 PM
"Pirate Logo" token, awarded by kislinsk.


On a few workstations in our department the Workbench didn't start (@cheray, @sattler). It's somehow related to QtOpenGL 5.6. "Luckily", @mpkh did have the same issue some weeks ago and he found a solution. In our mitk::BaseApplication we need to ensure the creation of an OpenGL context:

Thank you very much, @mpkh!

Event Timeline

@kislinsk is it already integrated? I can create PR for that if you wish

Not yet, but we will integrate it very soon. @gaehlert is currently testing if your fix resoves another issue on OS X in combination with QWebEngine as well.

Unfortunately, this does not resolve the rendering issues due to QWebEngine on Mac OS X.

Unfortunately, this does not resolve the rendering issues due to QWebEngine on Mac OS X.

We may need to fix this for our tutorial steps, too.

just finished a new superbuild on @sattler s PC ... the issue persists :/

@kirchnth Caspar told me that your issue is now a little bit different?
@mpkh Does the fix work for you?

Reverted the fix for now as the issue arose on even more PCs. However, the Workbench got stuck when loading QtWebEngine instead of QtOpenGL. So we may have a combination of issues here.

@kislinsk this fix works pretty fine for us, let me know if you will find some maybe better way to resolve it. or at least please share environment/video/steps to reproduce so we will know that there is something beyond my fix.

@kirchnth Caspar told me that your issue is now a little bit different?

No, I was wrong - it is exactly the same point

I just set up a complete new superbuild (mbi-mitk and mitk) and I have the same issues here. No build error, it starts to load the libraries but the workbench won't open.

I just set up a complete new superbuild (mbi-mitk and mitk) and I have the same issues here. No build error, it starts to load the libraries but the workbench won't open.

As I reverted the fix today, can you please check what version is actually working, if any?

Just for documentation: mitk rMITK3d2ff8ee (6th July) and mbi rMBI0694951b1006 (4th July) are working.

I'll set up a new superbuild with the current master and let you know if it is working.

Current master (rMITK8c57782b and rMBI9756551ed5) is working for me. Workbench is starting.

@mpkh Do you still remember how you came up with the OpenGL context solution?

After T19874: Make QtWebEngine an optional dependency I can reproduce the issue described here in T19851. When I switch on MITK_USE_QT_WEBENGINE, the Workbench doesn't start. It's happening somewhere in the Nvidia graphics driver. We should examine QWindowsOpenGLTester::testDesktopGL() for any hints. Here's the call stack:

[External Code] 
nvoglv64.dll!00000000641dcc32() Unknown
nvoglv64.dll!00000000641dc65a() Unknown
nvoglv64.dll!00000000641df07e() Unknown
nvoglv64.dll!00000000641dd5b1() Unknown
nvoglv64.dll!00000000641c607f() Unknown
nvoglv64.dll!00000000641ddb5e() Unknown
nvoglv64.dll!00000000641d9a9a() Unknown
nvoglv64.dll!00000000641d880b() Unknown
[External Code] 
qwindowsd.dll!QWindowsOpenGLTester::testDesktopGL() Line 365  C++
qwindowsd.dll!QWindowsOpenGLTester::detectSupportedRenderers(const GpuDescription & gpu, bool glesOnly) Line 240  C++
qwindowsd.dll!QWindowsOpenGLTester::supportedRenderers() Line 292 C++
qwindowsd.dll!QWindowsStaticOpenGLContext::doCreate() Line 380  C++
qwindowsd.dll!QWindowsStaticOpenGLContext::create() Line 407  C++
qwindowsd.dll!QWindowsIntegration::staticOpenGLContext() Line 441 C++
qwindowsd.dll!QWindowsIntegration::openGLModuleType() Line 427  C++
Qt5Guid.dll!QOpenGLContext::openGLModuleType() Line 1232  C++
Qt5WebEngineWidgetsd.dll!initialize() Line 54 C++
Qt5WebEngineWidgetsd.dll!`anonymous namespace'::initialize_ctor_class_::initialize_ctor_class_() Line 61  C++
Qt5WebEngineWidgetsd.dll!`anonymous namespace'::`dynamic initializer for 'initialize_ctor_instance_''() Line 61 C++
[External Code] 
Qt5Cored.dll!QLibraryPrivate::load_sys() Line 109 C++
Qt5Cored.dll!QLibraryPrivate::load() Line 532 C++
Qt5Cored.dll!QLibraryPrivate::loadPlugin() Line 580 C++
Qt5Cored.dll!QPluginLoader::load() Line 233 C++
CTKPluginFramework.dll!ctkPluginPrivate::start0() Line 729  C++
CTKPluginFramework.dll!ctkPluginPrivate::finalizeActivation() Line 370  C++
CTKPluginFramework.dll!ctkPlugin::start(const QFlags<enum ctkPlugin::StartOption> & options) Line 115 C++
liborg_blueberry_core_runtime.dll!berry::RegistryStrategy::CreateExecutableExtension(const berry::SmartPointer<berry::RegistryContributor> & contributor, const QString & className, const QString & __formal) Line 126 C++
liborg_blueberry_core_runtime.dll!berry::ExtensionRegistry::CreateExecutableExtension(const berry::SmartPointer<berry::RegistryContributor> & defaultContributor, const QString & className, const QString & requestedContributorName) Line 1044  C++
liborg_blueberry_core_runtime.dll!berry::ConfigurationElement::CreateExecutableExtension(const QString & attributeName) Line 239  C++
liborg_blueberry_core_runtime.dll!berry::ConfigurationElementHandle::CreateExecutableExtension(const QString & propertyName) Line 82  C++
liborg_blueberry_core_runtime.dll!berry::IConfigurationElement::CreateExecutableExtension<berry::IApplication>(const QString & propertyName) Line 108 C++
liborg_blueberry_core_runtime.dll!berry::ApplicationHandle::run(const QVariant & context_) Line 191 C++
CTKPluginFramework.dll!ctkDefaultApplicationLauncher::runApplication(const QVariant & defaultContext) Line 157  C++
CTKPluginFramework.dll!ctkDefaultApplicationLauncher::start(const QVariant & defaultContext) Line 85  C++
CTKPluginFramework.dll!ctkPluginFrameworkLauncher::run(const QVariant & argument) Line 486  C++
CTKPluginFramework.dll!ctkPluginFrameworkLauncher::run(QRunnable * endSplashHandler, const QVariant & argument) Line 427  C++
MitkAppUtil.dll!mitk::BaseApplication::main(const std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > & args) Line 696 C++
PocoUtild.dll!Poco::Util::Application::run() Line 333 C++
MitkAppUtil.dll!mitk::BaseApplication::run() Line 794 C++
MitkWorkbench.exe!main(int argc, char * * argv) Line 41 C++
[External Code]

Line 365 in QWindowsOpenGLTester::testDesktopGL() is a call to MakeCurrent().


QOpenGLContext can be moved to a different thread with moveToThread(). Do not call makeCurrent() from a different thread than the one to which the QOpenGLContext object belongs. A context can only be current in one thread and against one surface at a time, and a thread only has one context current at a time.

Maybe this is a first hint.

I could reproduce that error at home yesterday and updating to 5.6.1 did not fix it for me

This comment was removed by kislinsk.

I found a hot candidate for fixing this issue.

To make sure that OpenGL context can be shared between the GUI and render processes, the web engine must be initialized by using QtWebEngine::initialize in the application main source file, as illustrated by the following code snippet:

int main(int argc, char *argv[])
    QGuiApplication app(argc, argv);

    QQmlApplicationEngine engine;

    return app.exec();