Building using CMake - crash on start due to problem loading QtQuick Controls [macOS]

• Dec 17, 2020 - 12:10

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 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:
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/"
unknown:unknown: loaded library "/Users/matan/code/MuseScore/cmake-install-debug/"


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

For now my workaround is sufficient but are there any tips how to solve it properly?


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 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 in MsQmlEngine). This is contrary to the documentation, by the way. I worked around this bug by adding this in msqmlengine.cpp:

       QDir dir(mscoreGlobalShare + QString("/qml"));
+      if ("QtQuick/Controls.2")) {
+            QQuickStyle::addStylePath(dir.absolutePath());
+      }

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 by matangover

Well, I tried it, on Windows:

a) it needs a #include <QQuickStyle> to even compile
b) 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 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.

Do you still have an unanswered question? Please log in first to post your question.