Exception on latest release (Jul 26)

[freesig]

To reproduce just resize the window.
Error:

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

Callstack:

__cxa_throw (@7fff5690ef28..7fff5690ef99:3)
std::__1::__throw_system_error(int, char const*) (@7fff5690209a..7fff569020fc:24)
std::__1::mutex::lock() (@7fff568bc950..7fff568bc976:13)
MVKSemaphore::signal() (@1064f1bf0..1064f1c50:11)
MVKSwapchainImage::makeAvailable() (@106492070..1064921d0:76)
___ZN17MVKSwapchainImage22presentCAMetalDrawableEPU27objcproto16MTLCommandBuffer11objc_object_block_invoke (@106492a60..106492a80:10)
_doMTLDispatch (@7fff322b66ef..7fff322b6735:17)
-[_MTLCommandBuffer didCompleteWithStartTime:endTime:error:] (@7fff322b6a1f..7fff322b6cdc:108)
-[MTLIOAccelCommandBuffer didCompleteWithStartTime:endTime:error:] (@7fff322b69a6..7fff322b6a1f:25)
-[_MTLCommandQueue commandBufferDidComplete:startTime:completionTime:error:] (@7fff322b6828..7fff322b69a6:58)
ioAccelCommandQueueBlockFenceCallback (@7fff4aaa96a6..7fff4aaa9743:20)
IODispatchCalloutFromCFMessage (@7fff30040637..7fff30040804:111)
_IODispatchCalloutWithDispatch (@7fff3004060c..7fff30040637:13)
dispatch_mig_server (@7fff59658a79..7fff59658d08:105)
_dispatch_client_callout (@7fff59642635..7fff5964266a:8)
_dispatch_continuation_pop (@7fff59644c48..7fff59644ee2:113)
_dispatch_source_invoke (@7fff5965373a..7fff596543b1:532)
_dispatch_lane_serial_drain (@7fff59648686..7fff59648c7e:69)
_dispatch_lane_invoke (@7fff59649215..7fff59649729:105)
_dispatch_workloop_worker_thread (@7fff59651497..7fff59651e0e:139)

This has shown up on:
MacOS 10.14.6 and 10.13.06

[billhollings]

@freesig

Resizing the MoltenVK cube demo does not cause any issues.

It looks like the semaphore is being destroyed before the swapchain has finished using it. MoltenVK guards against that...and not a lot has changed in that code since the previous SDK release.

What version of SDK/MoltenVK were you using before this issue appeared?

Are you able to modify the Cube demo to cause this to happen? If so...please post a modified cube.c here.

Are you able to provide a sample that causes this issue?

[freesig]

Hey sorry I've been away. I was on the June release and it was working and now not on the July.
There is another user that has the same issue.
Any of the vulkano examples or nannou examples are hitting this.
I will try out the cube.c tonight and let you know.

[billhollings]

@freesig Any further info on the repeatability of this? Are you able to get cube.c to fail in the same way?

[FunMiles]

@billhollings , I am experiencing the same issue quite randomly. If I resize the window manually, it is always in the same spot (and happens almost always after just a few calls), when I call graphicsQueue.waitIdle(); ( I am using the C++ interface in vulkan.hpp ).
If I just maximize the window and then put it back into its original size, it happens less often but also at a call to vkCreateSwapchainKHR
I had used version 1.1.114.0 before and had not seen it happen. But with 1.1.121.0, it makes it effectively impossible to resize the window without crash.

PS: Any workaround to the waitIdle issue before a fix would already help me.

[billhollings]

@FunMiles Can you provide any further diagnostics?

Can you ZIP up a sample app that demonstrates the issue? Or if that is not possible, can you provide call stack of the crash?

[FunMiles]

@billhollings I put the crash report into: https://pastebin.com/3EFtqw35
Note that the crash report says thread 5 crashed. But it is always triggered by the call on the 9th frame of thread 0, which is the last call that I control.
As for a zip, I can possibly bundle the full app executable. Would that help? My app has grown too much by now for me to quickly try to create a small sample. I may try though if this call stack log is not enough for telling you what may be going on.

[FunMiles]

@billhollings The problem does not happen on the sample cube code.
However I think there is a fundamental difference that is probably at the root of the issue.
In the cube example, the same thread handles the drawing and the resizing.
I wrote my code to have a Qt based GUI and windowing system. There's a separate thread doing the drawing. That thread is put in temporary sleep during the resize. But maybe that is why there's a difference in behavior with the cube example.