Qt-5.14.0: Vulkan under QML causes std::system_error:: mutex lock failed

Question

The Vulkan under QML example runs for at most a couple of seconds before crashing with the following error:

libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument

While the animation looks correct during operation, the QML label is not displayed correctly:

I'm running macOS Catalina with MoltenVK 1.1.130 (LunarG Vulkan SDK) and Qt 5.14.0. I've also tried MoltenVK 1.2.131, with the same result. When using MoltenVK with MVK_LOG_LEVEL_INFO enabled, the following message is printed twice every frame:

[mvk-info] vkCreateMacOSSurfaceMVK(): You are not calling this function from the main thread. NSView should only be accessed from the main thread. When using this function outside the main thread, consider passing the CAMetalLayer itself in VkMacOSSurfaceCreateInfoMVK::pView, instead of the NSView.

Question

Does anyone know what could cause this? Is this a bug? Has anyone run this example successfully?

The MVK error message makes it appear a though the Vulkan integration of Qt is broken: Not only is vkCreateMacOSSurfaceMVK called twice every frame, but it also seems to be called from the render thread (not the GUI thread/main thread).

Details

In order to even use Qt with Vulkan, you must compile Qt from source and provide the Vulkan headers. The configuration call I used to compile Qt is:

../qt5/configure -developer-build -skip qtquick3d -skip qtwebengine -opensource -nomake examples -nomake tests -confirm-license -vulkan -I $VULKAN_SDK/../MoltenVK/include -L $VULKAN_SDK/lib

My environment variables are set according to the LunarG documentation:

export VULKAN_SDK="$HOME/SDK/vulkansdk-macos-1.1.130.0/macOS"
export PATH="$VULKAN_SDK/bin:$PATH"
export DYLD_LIBRARY_PATH="$VULKAN_SDK/lib:$DYLD_LIBRARY_PATH"
export VK_ICD_FILENAMES="$VULKAN_SDK/etc/vulkan/icd.d/MoltenVK_icd.json"
export VK_LAYER_PATH="$VULKAN_SDK/etc/vulkan/explicit_layer.d"
export VK_INSTANCE_LAYERS="VK_LAYER_KHRONOS_validation"

export QT_VULKAN_LIB="$VULKAN_SDK/lib/libMoltenVK.dylib"

(Qt requires the QT_VULKAN_LIB to dlopen the library.)

lldb backtrace:

[mvk-info] vkCreateMacOSSurfaceMVK(): You are not calling this function from the main thread. NSView should only be accessed from the main thread. When using this function outside the main thread, consider passing the CAMetalLayer itself in VkMacOSSurfaceCreateInfoMVK::pView, instead of the NSView.
[mvk-info] vkCreateMacOSSurfaceMVK(): You are not calling this function from the main thread. NSView should only be accessed from the main thread. When using this function outside the main thread, consider passing the CAMetalLayer itself in VkMacOSSurfaceCreateInfoMVK::pView, instead of the NSView.
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
Process 83453 stopped
* thread #10, name = 'QSGRenderThread', stop reason = signal SIGABRT
    frame #0: 0x00007fff648c57fa libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff648c57fa <+10>: jae    0x7fff648c5804            ; <+20>
    0x7fff648c57fc <+12>: movq   %rax, %rdi
    0x7fff648c57ff <+15>: jmp    0x7fff648bfa89            ; cerror_nocancel
    0x7fff648c5804 <+20>: retq   
Target 0: (main) stopped.
(lldb) frame info
frame #0: 0x00007fff648c57fa libsystem_kernel.dylib`__pthread_kill + 10
(lldb) frame variable
(lldb) bt
* thread #10, name = 'QSGRenderThread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff648c57fa libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff64982bc1 libsystem_pthread.dylib`pthread_kill + 432
    frame #2: 0x00007fff6484ca1c libsystem_c.dylib`abort + 120
    frame #3: 0x00007fff618e6be8 libc++abi.dylib`abort_message + 231
    frame #4: 0x00007fff618e6d84 libc++abi.dylib`demangling_terminate_handler() + 238
    frame #5: 0x00007fff63412792 libobjc.A.dylib`_objc_terminate() + 104
    frame #6: 0x00007fff618f3dc7 libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff618f3d79 libc++abi.dylib`std::terminate() + 41
    frame #8: 0x0000000103942439 libQt5Core_debug.5.dylib`qTerminate() at qglobal.cpp:3333:5
    frame #9: 0x000000010341f5f8 libQt5Core_debug.5.dylib`QThreadPrivate::start(arg=0x000000011721cfb0) at qthread_unix.cpp:354:9
    frame #10: 0x00007fff64982e65 libsystem_pthread.dylib`_pthread_start + 148
    frame #11: 0x00007fff6497e83b libsystem_pthread.dylib`thread_start + 15

@JesperJuhl Probably not to Qt. I just got the exact same error message after a crash. LWJGL, GLFW, Vulkan, MoltenVK, Metal. Rendering on secondary thread. Happened while resizing the window. It's probably not an error in Qt, but rather in Metal or MoltenVK. — Andreas is moving to Codidact, Mar 04 '20 at 20:21
@Andreas-he-her- That's interesting. Are you calling `vkCreateMacOSSurfaceMVK` on a secondary thread? — mkl, Mar 04 '20 at 20:26
@mkl No, I don't have access to that function, but GLFW likely calls it from within `glfwCreateWindowSurface`, which I do call on a secondary thread. Its documentation states: `This function may be called from any thread. For synchronization details of Vulkan objects, see the Vulkan specification.` I never call it more than once, which is in the setup code. Never had any problem until this sudden crash. — Andreas is moving to Codidact, Mar 04 '20 at 20:30
@mkl Yes. Spent a long time resizing the window in all different directions, and a after a minute or two of almost continuous resizing, it crashed again, with the same error. — Andreas is moving to Codidact, Mar 04 '20 at 20:47
@Andreas-he-her- According to the docs, `NSView` is not thread-safe (in fact, it's main thread only), so you're most likely venturing into undefined behavior when ignoring Apple's warning, thus making it a possible cause for the STL error. — mkl, Mar 04 '20 at 21:11
@mkl I'm well aware of the threading limitations in software rendering, but remembering correctly from the time I did some simple Metal programming, this was not an issue using Metal, and separate rendering threads is recommended multiple places. I found an [issue](https://github.com/KhronosGroup/MoltenVK/issues/510) posted in MoltenVK's repository, with a dedicated rendering thread as well, where it seems as if this is a fine approach. — Andreas is moving to Codidact, Mar 16 '20 at 19:23
@Andreas-he-her- "[...] where it seems as if this is a fine approach." - Using `vkCreateMacOSSurfaceMVK` on a secondary thread is fine as long as `pView` is a `CAMetalLayer`. That doesn't seem to be the case in the example you're giving, where `NSView` is used. — mkl, Mar 18 '20 at 10:57

mkl · Accepted Answer · 2020-04-15T15:26:11.883

1

I've reported the issue: QTBUG-82600

The fix was merged into Qt 5.15.0 beta2. Although the crashes no longer occur, the text remains mangled. The fix for that is postponed until Qt6: QTBUG-83072

edited Apr 15 '20 at 15:26

answered Mar 04 '20 at 15:16

mkl

635
1
6
16

"I've reported the issue" - – Jesper Juhl Mar 04 '20 at 20:34

Qt-5.14.0: Vulkan under QML causes std::system_error:: mutex lock failed

Question

Details

1 Answers1