Open TheMrButcher opened 3 months ago
Any update about this problem?
It looks like there's an object lifetime issue here, where an object has been destroyed, but Metal still has an outstanding command buffer out for it, so when the completion handler tries to report the failure, the app crashes.
I wonder if, once the device is lost, completion handlers for any remaining outstanding command buffers should just exit as quickly as possible, without even trying to report the error to the log. Regardless, we're definitely missing a call to MVKBaseObject::retain()
somewhere in MVKQueueCommandBufferSubmission
.
I am using MoltenVK on iOS, and I get a lot of VK_ERROR_DEVICE_LOST during work of application. I am trying to add support of this error code and recreate logical device when this happens. The problem is that I can't use vkDeviceWaitIdle to wait for stop of all work. Due to specs vkDeviceWaitIdle can and will return VK_ERROR_DEVICE_LOST if device is lost. And according to code of MoltenVK it is doing nothing on lost device.
So it seems to me that I don't have any way to wait until all command buffer submissions are finished. Without this wait I get a lot of crashes with this trace in thread that is managed by MoltenVK (or Metal) just after deletion of device: