Building using CMake - crash on start due to problem loading QtQuick Controls [macOS]
Hi all,
I cloned MuseScore (3.x branch tip) and compiled it using CMake on macOS, and then ran cmake --install as in the instructions. When I try to launch the app, it shows the splash screen and then crashes during the 'Initializing main window' stage. I found that the crash is due to loading libqtquickcontrols2plugin twice.
If I go into the generated mscore.app in the install dir, and rename Contents/Resources/QtQuick/Controls.2/libqtquickcontrols2plugin.dylib to libqtquickcontrols2plugin.dylib.orig, then the crash doesn't occur anymore.
Is this a known problem? Did I do something wrong?
When I run the executable using debugging variables:
QT_DEBUG_PLUGINS=1 QML_IMPORT_TRACE=1 mscore.app/Contents/MacOS/mscore
I can see that it successfully loads libqtquickcontrols2plugin.dylib from Resources/qml (since it is imported from PalettesWidget.qml) and after that it tries to load libqtquickcontrols2plugin.dylib from my global Qt installation:
/usr/local/Cellar/qt/5.15.1/qml/QtQuick/Controls.2/libqtquickcontrols2plugin.dylib, at which point it crashes.
unknown:unknown: QQmlImports(qrc:/qml/palettes/PalettesWidget.qml)::importExtension: loaded "/Users/matan/code/MuseScore/cmake-install-debug/mscore.app/Contents/Resources/qml/QtQuick.2/qmldir"
unknown:unknown: loaded library "/Users/matan/code/MuseScore/cmake-install-debug/mscore.app/Contents/Resources/qml/QtQuick/Controls.2/libqtquickcontrols2plugin.dylib"
[...]
unknown:unknown: loaded library "/usr/local/Cellar/qt/5.15.1/qml/QtQuick/Controls.2/libqtquickcontrols2plugin.dylib"
[1] 21371 segmentation fault QT_DEBUG_PLUGINS=1 QML_IMPORT_TRACE=1 mscore.app/Contents/MacOS/mscore
For now my workaround is sufficient but are there any tips how to solve it properly?
Comments
Don't build 3.X with Qt 5.15; use 5.9 or 5.12
In reply to Don't build 3.X with Qt 5.15… by jeetee
Thanks
Same issue on Windows too (and for that I've amended the developers' handbook to mention that, not for Mac though)
That double loading though might be the hint on how to fix this?!?
In reply to Same issue on Windows too … by Jojo-Schmitz
I think so. The crash is in the QML loading thread
In reply to I think so. The crash is in… by matangover
seeing it loading directly from the Qt installation might mean that it won't crash for people not having installed the build environent?
In reply to seeing it loading directly… by Jojo-Schmitz
The double loading might be a red herring though. Because it happens on my system also for the (working) Qt 5.12 build.
In reply to seeing it loading directly… by Jojo-Schmitz
The double loading was indeed the problem after all. The plugin was being loaded for the second time because of QQuickStyle. This is probably a bug in Qt: in Qt sources I see that
QQuickStyle::stylePaths
uses the default QML import path to load styles rather than the current import path (which is set by MuseScore inMsQmlEngine
). This is contrary to the documentation, by the way. I worked around this bug by adding this in msqmlengine.cpp:This adds the correct style path for QtQuick Controls at the beginning of the style import path, before the system directory (which it seems cannot be removed unfortunately). I could submit a PR if you tell me you like this workaround. I assume on Windows the solution is identical but can't test.
In reply to The double loading was the… by matangover
Well, I tried it, on Windows:
a) it needs a
#include <QQuickStyle>
to even compileb) this would need to be guarded by
#if (QT_VERSION >= QT_VERSION_CHECK(5, 12, 0))
to prevent it from getting used prior to Qt 5.12 (for the 3.x branch, which still uses 5.9 for the release builds)c) it still crashes on Windows, when building against Qt 5.15(.2), directly on startup, after showing the splash screen, "Restoring Session" are the 'famous last words' there. But then again this crash might be something entirely different, as it doesn't happen with Qt 5.12.
In reply to Well, I tried it, on Windows… by Jojo-Schmitz
Thanks for testings.
a) sorry, I omitted the include for brevity
b) right
c) oh well :( I guess there are probably other compatibility problems to fix...
In reply to Thanks for testings. a)… by matangover
It it helps on the Mac part, please PR it.
And doing the same on the Windows part of the code at least doesn't harm ;-)
In reply to It it helps on the Mac part,… by Jojo-Schmitz
Should I open the PR against the 3.x branch?
In reply to Should I open the PR against… by matangover
Yes
In reply to Thanks for testings. a)… by matangover
Initially I thought this code is active only in debug builds. Now I see it's for all builds. Tbh I don't feel comfortable making this change without proper testing on several Qt versions and OS versions, debug and release. So I'll leave it here for now, at least it's Googleable. Sorry.
In reply to Thanks for testings. a)… by matangover
Unless you say you want it in there anyway, in which case I will happily PR.