Page MenuHomePhabricator

Workbench does not start when building with Qt 5.15 on Linux
Open, HighPublic


It crashes with a memory corruption error (invalid free), maybe caused by an unhandled exception or otherwise side effect of destruction of the stack objects. Just an assumption based on the code comments in the method causing the crash:


This is during startup, so some plugin loading through CTK and Qt and dlopen, so I suspect there was some change in Qt 5.15 which changed the behaviour.

I did not yet do any further debugging, but using Qt 5.12 on an otherwise identical setup does work

Event Timeline

And I just tested: as expected the unit tests do pass, I think it has to be a side effect of dlopen'ing the activator

If this is caused in UseRegEx() then its preconditions are not meet anymore. Meaning that for whatever reasons the RegEx strings are not valid any more when using Qt 5.15. I would also guess that something in the intialization behavior changes and therfore some string constants are not initialized when used.
Which activator causes this?

It's the CoreActivator if I read this correcty:

#11 0x00007fffbd56df3a in mitk::PropertyPersistenceInfo::UseRegEx (       
    nameRegEx="MITK\\.IO\\.reader\\.option\\.([a-zA-Z0-9- ]+)",                          
    keyRegEx="MITK_IO_reader_option_([a-zA-Z0-9- ]+)",                                                                       
    at /home/nolden/prj/mitk/src/Modules/Core/src/DataManagement/mitkPropertyPersistenceInfo.cpp:112

Coming from

#12 0x00007fffbc776001 in AddPropertyPersistence (propPath=...) 
    at /home/nolden/prj/mitk/src/Modules/Core/src/mitkCoreActivator.cpp:129                        
#13 0x00007fffbc776c09 in MitkCoreActivator::Load (this=0xc77570,                                                            
--Type <RET> for more, q to quit, c to continue without paging--
    at /home/nolden/prj/mitk/src/Modules/Core/src/mitkCoreActivator.cpp:218                                                  
#14 0x00007ffff70cab09 in us::Module::Start (this=0x11d9830)
    at /home/nolden/prj/mitk/src/Modules/CppMicroServices/core/src/module/usModule.cpp:156
#15 0x00007ffff70dca07 in us::ModuleRegistry::Register (info=0x1073300)                                                      
    at /home/nolden/prj/mitk/src/Modules/CppMicroServices/core/src/module/usModuleRegistry.cpp:127                           
#16 0x00007fffbc77865d in us::(anonymous namespace)::ModuleInitializer_MitkCore::Register ()
    at /home/nolden/prj/mitk/src/Modules/Core/src/mitkCoreActivator.cpp:365                                                  
#17 0x00007fffbc7785f6 in us::(anonymous namespace)::ModuleInitializer_MitkCore::ModuleInitializer_MitkCore (
    this=0x7fffbe0f66d0 <us::(anonymous namespace)::_InitializeModule_MitkCore>) at /home/nolden/prj/mitk/src/Modules/Core/sr
#18 0x00007fffbc778837 in __static_initialization_and_destruction_0 (           
    __initialize_p=1, __priority=65535)                                                                                      
    at /home/nolden/prj/mitk/src/Modules/Core/src/mitkCoreActivator.cpp:365 
#19 0x00007fffbc77888e in _GLOBAL__sub_I_mitkCoreActivator.cpp(void) ()
    at /home/nolden/prj/mitk/src/Modules/Core/src/mitkCoreActivator.cpp:365
#20 0x00007ffff7fe18ee in call_init.part () from /lib64/
#21 0x00007ffff7fe19d8 in _dl_init () from /lib64/

Valgrind shows some reading beyond memory boundaries, around mitkCoreActivator.cpp:129 and 218. Since it is the last line of all the AddPropertyPersistence calls there and all the creating of temp objects in there, I was wondering if it could be some reference to deleted temp objects issues. Just an idea.

I didn't really look into this but it reminds me of something I stumbled over a few weeks ago. There's a bug in C++ 14 regex regarding temporary strings:

Interesting catch. There is no call to regex_match in our code. If I understand it correctly the stack object is just created to check if an exception happens during construction, but maybe this is just another variant of the issue described for the library. A possible workaround could be to explicitly create and destroy the regex objects in our code, with explicit exception catching and re-throwing.

Just observed the same problem with latest "develop" of today.