macOS segfault on launch due to relocatable Qt

[Benjamin Englert]

Using the latest environment,

2.3-j00006-b887bce2-osx10.11-x86_64-release.tar.gz

a build from scratch of mixxx master branch segfaults at launch:

Bens-MacBook-Pro:mixxx ben$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.4
BuildVersion: 19E266
Bens-MacBook-Pro:mixxx ben$ cat ~/Code/mixxxenv/env.sh
export OSXLIB=/Users/ben/Code/mixxxenv;
# Make sure to edit this to match what is actually present in $OSXLIB.
export QTDIR=${OSXLIB}/Qt-5.14.1;
export PATH=${OSXLIB}/bin:${QTDIR}/bin:$PATH;
export CXXFLAGS="-isystem ${OSXLIB}/include";
export CFLAGS="-isystem ${OSXLIB}/include"
export LDFLAGS="-L${OSXLIB}/lib -F${OSXLIB}/lib -Wl,-rpath,${OSXLIB}/lib"; Bens-MacBook-Pro:mixxx ben$
Bens-MacBook-Pro:mixxx ben$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
Bens-MacBook-Pro:mixxx ben$ ./mixxx --resourcePath res/
Warning [Main]: Failed to add font: "res/fonts/OpenSans-Bold.ttf"
Warning [Main]: Failed to add font: "res/fonts/OpenSans-Regular.ttf"
Warning [Main]: Failed to add font: "res/fonts/Ubuntu-B.ttf"
Warning [Main]: Failed to add font: "res/fonts/Ubuntu-R.ttf"
Segmentation fault: 11

[Be (be.ing)]

We just updated the build environment to Qt 5.14.1. Can you test if the latest build from our build server crashes too? http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-release-macintel64-latest.dmg

[Be (be.ing)]

Also can you attach a backtrace?

[Be (be.ing)]

Did you build with scons or cmake?

[Be (be.ing)]

Ugh this might have been caused by https://github.com/mixxxdj/mixxx/pull/2630
82577027821538aaaac493108d5713f6e15a89e1 is the merge commit for that pull request.

[Benjamin Englert (bengl3rt)]

I reproduce the crash with the bundle in the linked DMG also. Built with icons.

[Benjamin Englert (bengl3rt)]

built with scons* darn autocorrect

[Be (be.ing)]

Please try building commit 5fe4c858eb5bbf0948bf8eadfc850e12936d7490 and let us know if you can reproduce the crash.

[Benjamin Englert (bengl3rt)]

Yes it looks like it reproduces with that hash. Backtraces attached.

[Be (be.ing)]

Interesting backtrace... can you try renaming the file ~/Library/Application Support/Mixxx/samplers.xml ?

If that doesn't fix it, try building with the old build environment that has Qt 5.12.0: http://downloads.mixxx.org/builds/buildserver/2.3.x-macosx/2.3-j00004-497fe02e-osx10.11-x86_64-release.tar.gz

[Be (be.ing)]

Err, that build environment has Qt 5.12.4, not 5.12.0. There was a major performance issue on macOS with 5.12.0.

[Benjamin Englert (bengl3rt)]

That file doesn't exist, I've never launched Mixxx successfully on this machine (and have only attempted bleeding edge builds/bundles).

Bens-MacBook-Pro:mixxx ben$ file ~/Library/Application\ Support/Mixxx/samplers.xml
/Users/ben/Library/Application Support/Mixxx/samplers.xml: cannot open `/Users/ben/Library/Application Support/Mixxx/samplers.xml' (No such file or directory)

The build against the older Qt doesn't appear to want to launch at all:

Bens-MacBook-Pro:mixxx ben$ cat ~/Code/mixxxenv/2.3-j00004-497fe02e-osx10.11-x86_64-release/env.sh
export OSXLIB=/Users/ben/Code/mixxxenv/2.3-j00004-497fe02e-osx10.11-x86_64-release;
# Make sure to edit this to match what is actually present in $OSXLIB.
export QTDIR=${OSXLIB}/Qt-5.12.3;
export PATH=${OSXLIB}/bin:${QTDIR}/bin:$PATH;
export CXXFLAGS="-isystem ${OSXLIB}/include";
export CFLAGS="-isystem ${OSXLIB}/include"
export LDFLAGS="-L${OSXLIB}/lib -F${OSXLIB}/lib -Wl,-rpath,${OSXLIB}/lib"; Bens-MacBook-Pro:mixxx ben$
Bens-MacBook-Pro:mixxx ben$ ./mixxx --resourcePath res/ --debugLevel 2
Warning [Main]: Could not find the Qt platform plugin "cocoa" in ""
Fatal [Main]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Abort trap: 6

[Be (be.ing)]

Are you able to build Mixxx installing the dependencies from Homebrew?

[Foss-4 (foss-4)]

Confirmed. Opening todays master http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-git7224-release-macintel64.dmg results in crash (available 30 days):
https://bin.disroot.org/?37fa4ac7b883decc#5T3NiaHqnrNzbtw1D1DNw2Gaeu4ZJPVMhcEu3xpWoRko

mixxx-2.3.0-alpha-pre-master-git7221-release-macintel64.dmg 2020-04-05
crashes

mixxx-2.3.0-alpha-pre-master-git7219-release-macintel64.dmg 2020-04-04
opens fine

So breaking change was introduced 2020-04-04.

[Be (be.ing)]

Thanks for testing. Two Jenkins jobs ran between those builds:
https://builds.renegadetech.mixxx.org/job/master-release/architecture=amd64,platform=macosx/1040/
after merging the color preferences PR

https://builds.renegadetech.mixxx.org/job/master-release/architecture=amd64,platform=macosx/1042/
updated to the new macOS build environment

So I think the problem is with the new build environment.

[Be (be.ing)]

I can't explain the problem with the old build environment reported in comment #11, but it's different from the segmentation fault originally reported in this bug.

[Be (be.ing)]

Qt 5.14.2 was released 2 days after I updated the build environment. A new build environment with Qt 5.14.2 is building now:
https://builds.renegadetech.mixxx.org/job/v2.3/job/buildserver-2.3.x-macosx/8/
It should take about 8.5 hours.

I also set Jenkins to clear the workspace before each build. Hopefully between those two changes this will work.

[Be (be.ing)]

New macOS build with Qt 5.14.2 is here:
http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-git7231-release-macintel64.dmg
Please test and let us know if the crash remains.

[Be (be.ing)]

New build environment with Qt 5.14.2 is here:
http://downloads.mixxx.org/builds/buildserver/2.3.x-macosx/2.3-j00008-c18d8fda-osx10.11-x86_64-release.tar.gz

[Foss-4 (foss-4)]

Still crashing :(
https://bin.disroot.org/?102e58ca4d45e2fe#C4wGXmN7AgjfrPJMKw1CvJ8UgbSmjirPppahyHcELxkh
(30 days)

[Be (be.ing)]

Can you try building this branch? https://github.com/mixxxdj/mixxx/pull/2635

[Benjamin Englert (bengl3rt)]

Not sure which env/QT version you wanted me to build against, so I used the newest one from today:

Bens-MacBook-Pro:mixxx ben$ cat ~/Code/mixxxenv/2.3-j00008-c18d8fda-osx10.11-x86_64-release/env.sh
export OSXLIB=/Users/ben/Code/mixxxenv/2.3-j00008-c18d8fda-osx10.11-x86_64-release;
# Make sure to edit this to match what is actually present in $OSXLIB.
export QTDIR=${OSXLIB}/Qt-5.14.2;
export PATH=${OSXLIB}/bin:${QTDIR}/bin:$PATH;
export CXXFLAGS="-isystem ${OSXLIB}/include";
export CFLAGS="-isystem ${OSXLIB}/include"
export LDFLAGS="-L${OSXLIB}/lib -F${OSXLIB}/lib -Wl,-rpath,${OSXLIB}/lib";

I am seeing a different (but consistent) crashpoint than the one posted by Foss-4.

(lldb) bt
* thread #13, name = 'VinylControlProcessor', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007fff68bbd70a libdyld.dylib`stack_not_16_byte_aligned_error
    frame #1: 0x000070000f271fb0
    frame #2: 0x00007fff68dc3109 libsystem_pthread.dylib`_pthread_start + 148
    frame #3: 0x00007fff68dbeb8b libsystem_pthread.dylib`thread_start + 15

[Be (be.ing)]

Yeah that backtrace looks totally different from the one in #19 :( Maybe try running scons with vinylcontrol=0 ? I am somehow doubting that VinylControlProcessor is actually the problem...

[Be (be.ing)]

Ben, can you try the build that Foss-4 said was the last working one in #13? http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-git7219-release-macintel64.dmg

[Foss-4 (foss-4)]

http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-git7232-release-macintel64.dmg

https://bin.disroot.org/?4c8197a04598f47d#9LUsniUyCPHCvBeASoWsMopjJHLRi2RtMHNC6q5hq4Kr
(30 days)

[Daniel Schürmann (daschuer)]

I am not sure if you are on the right track.
The crash is:
```
* thread #12, name = 'VinylControlProcessor', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007fff68bbd70a libdyld.dylib`stack_not_16_byte_aligned_error
    frame #1: 0x0000700003125fb0
    frame #2: 0x00007fff68dc3109 libsystem_pthread.dylib`_pthread_start + 148
    frame #3: 0x00007fff68dbeb8b libsystem_pthread.dylib`thread_start + 15
```

.. in "libdyld"

This is is MacOSs dynamic linker.

I guess the crash disappears if we use here
https://github.com/mixxxdj/mixxx/blob/7b1f4d106b14b5be9bee1a2e3d192c07a5ec5055/src/vinylcontrol/vinylcontrolprocessor.cpp#L84
while(false)

Interestingly we have not a single debug info in the call stack. But the thread name is already set. This means we have passed https://github.com/mixxxdj/mixxx/blob/7b1f4d106b14b5be9bee1a2e3d192c07a5ec5055/src/vinylcontrol/vinylcontrolprocessor.cpp#L82

So maybe we are in the thread destroy code somehow.

[Daniel Schürmann (daschuer)]

If you search the web for "stack_not_16_byte_aligned_error" you find some explanations mentions AVX issues. Does the new QT version make more use of these registers?

[Be (be.ing)]

Maybe it is a compiler bug?
https://code.videolan.org/videolan/libbluray/issues/20#note_52578

[Benjamin Englert (bengl3rt)]

Using the bundle in mixxx-2.3.0-alpha-pre-master-git7232-release-macintel64.dmg, I reproduce the logging-related crash that's patched out on the macos_segfault_hack branch:

Process 33186 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x00007fff2ec195b8 CoreFoundation`CFBundleCopyBundleURL + 9
CoreFoundation`CFBundleCopyBundleURL:
-> 0x7fff2ec195b8 <+9>: movq 0x10(%rdi), %rdi
    0x7fff2ec195bc <+13>: testq %rdi, %rdi
    0x7fff2ec195bf <+16>: je 0x7fff2ec195cc ; <+29>
    0x7fff2ec195c1 <+18>: callq 0x7fff2ebf6b9b ; CFRetain
Target 0: (Mixxx) stopped.

However, building locally from either master OR the macos_segfault_hack branch, I get the crash in the VinylControlProcessor thread.

Good news (?) is that `scons verbose=0 vinylcontrol=0 -j 2` *appears* to fix the problem, and lets me launch my top-of-tree local build of Mixxx.

[Benjamin Englert (bengl3rt)]

I am indeed running a version of clang that the VLC folks would consider troublesome:

Bens-MacBook-Pro:mixxx ben$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.29)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[Be (be.ing)]

What if you build master locally using dependencies from Homebrew rather than our prebuilt environment?

[Daniel Schürmann (daschuer)]

If this is a Compiler Bug, it would be interesting which statement triggers the bug.
If this is related to avx instructions, we may disable the flags for this Compiler version.
Or we just reject building with this Compiler.

Typically such issue come and go depending which memory is sllig ef before.
So even if we find a state that does not crash it csnncrash again at any future change, changing memory allocations.

Do we have the prove that the Qt version triggers the issue? Does the release include any avx register optimisation?

[Be (be.ing)]

> Do we have the prove that the Qt version triggers the issue?

As reported in comment #13, the crashes started when the new build environment was first used. The change to the build environment was upgrading Qt. AFAIK nothing else changed on the build server that would change the produced build environment.

[Be (be.ing)]

Ben, if you update XCode and build master using our prebuilt environment, does it still crash?

[Benjamin Englert (bengl3rt)]

Nope, master builds and runs happily on the same build of macOS with the same environment but a newer clang (different machine cause the other one is out of disk space):

ben@Banger-Factory mixxx % sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.4
BuildVersion: 19E287
ben@Banger-Factory mixxx % clang --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
ben@Banger-Factory mixxx %

[Be (be.ing)]

Well that's interesting. The Clang version string that you said is working (1100.0.33.17) corresponds to XCode 11.3.1, but the Clang version that didn't work (1103.0.32.29) corresponds to XCode 11.4.
https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_11.x_(since_Free_On-Device_Development)

On that VLC bug report, they said that XCode 11.0 through 11.2 had the bug. The user who reported that bug with VLC said that it worked with the same compiler you say works with XCode 11.3.1.

Maybe there is some other difference between the machines you built on. Can you try the latest build from our build server on the machine you did the working build? http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-git7243-release-macintel64.dmg

Another puzzling aspect to this is that the version of clang on our build server is 900.0.31. I can't find what version of XCode this version of clang corresponds to that table on Wikipedia nor searching the web. The closest match is XCode 9.0. Perhaps this is actually an old bug that was present in Clang for a long time but somehow didn't come out until building Mixxx with Qt 5.14.

[Benjamin Englert (bengl3rt)]

The build in mixxx-2.3.0-alpha-pre-master-git7243-release-macintel64.dmg does *not* launch on the machine (Banger-Factory) that produced the working build using clang 1100.0.33.17, instead crashing here:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [7071]

VM Regions Near 0x10:
-->
    __TEXT 000000010280c000-0000000103340000 [ 11.2M] r-x/rwx SM=COW /Users/USER/Desktop/Mixxx.app/Contents/MacOS/Mixxx

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff3636b5b8 CFBundleCopyBundleURL + 9
1 QtCore 0x000000010396b6b9 QLibraryInfo::location(QLibraryInfo::LibraryLocation) + 1369
2 QtCore 0x000000010396b980 QLibraryInfo::location(QLibraryInfo::LibraryLocation) + 2080
3 QtCore 0x0000000103b61b95 QCoreApplication::libraryPathsLocked() + 1637
4 QtCore 0x0000000103b5dd9b QCoreApplication::libraryPaths() + 43
5 QtCore 0x0000000103b4c574 QFactoryLoader::update() + 36
6 QtCore 0x0000000103b4de20 QFactoryLoader::QFactoryLoader(char const*, QString const&, Qt::CaseSensitivity) + 224
7 QtGui 0x00000001041924ff QGlobalStatic<QFactoryLoader, (anonymous namespace)::Q_QGS_loader::innerFunction(), (anonymous namespace)::Q_QGS_loader::guard>::operator()() + 143
8 QtGui 0x000000010419290a QPlatformIntegrationFactory::keys(QString const&) + 858
9 QtGui 0x000000010419f98a QGuiApplicationPrivate::createPlatformIntegration() + 1626
10 QtGui 0x00000001041a0ffb QGuiApplicationPrivate::createEventDispatcher() + 27
11 QtCore 0x0000000103b5d9bc QCoreApplicationPrivate::init() + 1708
12 QtGui 0x000000010419b4f9 QGuiApplicationPrivate::init() + 57
13 QtWidgets 0x00000001051da78f QApplicationPrivate::init() + 31
14 org.mixxx.mixxx 0x0000000102c3ae51 MixxxApplication::MixxxApplication(int&, char**) + 17

I am not running Xcode but rather the command line tools (Xcode-select --install); I tried "updating" the other machine (Bens-MacBook-Pro) to the latest version of those assuming it would include clang 1100.0.33.17, but it still shows 1103.0.32.29, so that must be considered "newest". I guess if you go by the outer version numbers (11.0.0 vs 11.0.3), Banger-Factory has an older clang on it. I'm now hesitant to update it since it's the one that lets me produce a working build :)

[RJ Skerry-Ryan (rryan)]

Versions on the build server VM:

$ xcodebuild -showsdks
iOS SDKs:
 iOS 11.4 -sdk iphoneos11.4

iOS Simulator SDKs:
 Simulator - iOS 11.4 -sdk iphonesimulator11.4

macOS SDKs:
 macOS 10.13 -sdk macosx10.13

tvOS SDKs:
 tvOS 11.4 -sdk appletvos11.4

tvOS Simulator SDKs:
 Simulator - tvOS 11.4 -sdk appletvsimulator11.4

watchOS SDKs:
 watchOS 4.3 -sdk watchos4.3

watchOS Simulator SDKs:
 Simulator - watchOS 4.3 -sdk watchsimulator4.3

$ xcodebuild -version
Xcode 9.4.1
Build version 9F2000

$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[RJ Skerry-Ryan (rryan)]

Here is qobject.cpp compiler invocation in Qt 5.12.? (build 5 from Sep 2019):

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -include.pch/QtCore/c++_x86_64 -pipe -stdlib=libc++ -g -O3 -std=c++1y -fapplication-extension -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Winconsistent-missing-override -Wobjc-interface-ivars -Wobjc-method-access -Wobjc-multiple-method-names -Werror=unguarded-availability -Werror=unguarded-availability-new -Werror=unsupported-availability-guard -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DPCRE2_CODE_UNIT_WIDTH=16 -I. -I../3rdparty/zlib/src -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty -I../3rdparty/double-conversion/include -I../3rdparty/double-conversion/include/double-conversion -I../3rdparty/forkfd -I../3rdparty/tinycbor/src -I../../include -I../../include/QtCore -I../../include/QtCore/5.12.3 -I../../include/QtCore/5.12.3/QtCore -I.moc -I.tracegen -I../3rdparty/pcre2/src -I/Users/mixxx/bs-2.3-mac/amd64/environment/2.3-j00005-0a61174e-osx10.11-x86_64-release/include -I../../mkspecs/macx-clang -o .obj/qobject.o kernel/qobject.cpp

Here is the qobject.cpp compiler invocation in Qt 5.14.2 (build 8)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -include.pch/QtCore_x86_64.pch/c++_x86_64 -pipe -stdlib=libc++ -g -O3 -std=c++1y -fapplication-extension -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.13 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -Winconsistent-missing-override -Wobjc-interface-ivars -Wobjc-method-access -Wobjc-multiple-method-names -Werror=unguarded-availability -Werror=unguarded-availability-new -Werror=unsupported-availability-guard -fPIC -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_DEPRECATED_WARNINGS_SINCE=0x060000 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DPCRE2_CODE_UNIT_WIDTH=16 -I. -I../3rdparty/zlib/src -Iglobal -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty -I../3rdparty/double-conversion/include -I../3rdparty/harfbuzz/src -I../3rdparty/forkfd -I../3rdparty/tinycbor/src -I../../include -I../../include/QtCore -I../../include/QtCore/5.14.2 -I../../include/QtCore/5.14.2/QtCore -I.moc -I.tracegen -I../3rdparty/pcre2/src -I/Users/mixxx/bs-2.3-mac/amd64/environment/2.3-j000...

[RJ Skerry-Ryan (rryan)]

The main diff I see is -mmacosx-version-min=10.12 vs -mmacosx-version-min=10.13.

[RJ Skerry-Ryan (rryan)]

The git7247 release build also segfaults for me on startup: https://paste.debian.net/1139828/
http://downloads.mixxx.org/builds/master/release/mixxx-2.3.0-alpha-pre-master-git7247-release-macintel64.dmg

I built 81a62fca5904697ae7d47158fb5c2a761428a7e2 locally with the 2.3-j00008-c18d8fda-osx10.11-x86_64-release environment on 10.14.6 with Xcode 11.3.1.

A debug build with optimize=portable launches fine, but many debug assertions are failing.
https://paste.debian.net/1139826/

I'm building in release mode with optimize=native now.

[RJ Skerry-Ryan (rryan)]

build=release optimize=native also works on 81a62fca5904697ae7d47158fb5c2a761428a7e2 with the 2.3-j00008-c18d8fda-osx10.11-x86_64-release environment on 10.14.6 with Xcode 11.3.1.

The build is disturbingly slow and laggy -- with no decks playing the CPU usage is very high and it takes a few seconds for actions to complete (like opening the sidebar in Deere, or opening preferences).

[RJ Skerry-Ryan (rryan)]

I can reproduce with a locally built binary if I bundle (not just build).

It looks like some bad interaction between QCoreApplication initialization and QLibraryLoader.

Looking at the code it's crashing around:
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qcoreapplication.cpp?h=5.14.2#n2685
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qlibraryinfo.cpp#n689
it looks like this is something related to determining plugin paths.

I'll build the environment locally so I can stick some printlines in Qt.

[Be (be.ing)]

Great, thank you for looking into this tricky bug RJ.

[RJ Skerry-Ryan (rryan)]

My locally built environment (macOS 10.5 SDK, Xcode 11.3.1) successfully repros the issue.

The crash happens on this line:
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qlibraryinfo.cpp?h=5.14.2#n559
qtCoreBundle is nullptr, and CFBundleCopyBundleURL doesn't seem to check for null.

I believe this is because we don't ship Qt as frameworks on macOS, we ship the raw library dylibs outside of a framework. So the "bundle" lookups on this line:
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qlibraryinfo.cpp?h=5.14.2#n538
for QtCore's bundle are failing.

This code was added in this commit (9/2019):
https://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/global/qlibraryinfo.cpp?h=5.14.2&id=4ac872639ed0dd3ae6627e05bdda821f7d128500
which I think is new in Qt 5.14.

And it looks like they already tried to mitigate the crash when the bundle is not found:
https://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/global/qlibraryinfo.cpp?h=5.14.2&id=d0e9e5a36e3e49ec9fb0fb3f1639c21e7414c615

It would be nice if they fell back on the dlopen approach instead of just crashing...

Here's my list of fixes, in order to try:
- Disable the new relocatable feature: -no-relocatable
- Disable the frameworks feature (since we don't actually ship frameworks): -no-framework
- Switch to shipping frameworks instead of individual dylibs.

[RJ Skerry-Ryan (rryan)]

I'm trying -no-relocatable now.

[RJ Skerry-Ryan (rryan)]

https://www.qt.io/blog/qt-is-relocatable
https://bugreports.qt.io/browse/QTBUG-14150

(The flag is -no-feature-relocatable)

We already have relocatable Qt builds via this script:
https://github.com/mixxxdj/buildserver/blob/2.3.x-unix/scripts/macosx/relocate_environment.py

[Be (be.ing)]

We use our own build of Qt, so patching Qt is an option. We could submit the fix upstream too.

[RJ Skerry-Ryan (rryan)]

Yea, upstreaming a patch makes sense if they consider this a bug. We are kind of doing something unusual by shipping standalone libraries while building with frameworks enabled.

I think disabling the framework build makes sense given we're shipping without frameworks, but it might imply other changes in the build or packaging setup and so I think the most direct short term fix is -no-feature-relocatable.

[RJ Skerry-Ryan (rryan)]

Building with -no-feature-relocatable fixes the crash on start for me.
https://github.com/mixxxdj/buildserver/pull/86

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9920