While I can't think of anything that will go wrong as a result of this, I'd like to get the thoughts of @gaaclarke who introduced the DeviceHolder (flutter/engine@dab253347f2) to presumably handle cases like these. Per my understanding, the way he envisioned this would work was to first check if the holder had a live device. If it didn't, then you'd release the wrapper (and likely incur the small leak of the Vulkan object). In the case of the image, there is no chance of a leak of the image data itself because that is in the allocator which will be collected along with the device.

To put another way, instead of delaying collection of all live objects in the allocator till all textures are collected, just don't collect the texture if the allocator is dead.

But yeah, I'll take the lead from @gaaclarke on this.

The challenge is that the Vulkan memory allocator apparently expects that all allocations will be freed before the allocator itself is shut down.

If the texture and its allocation are still alive when the AllocatorVK is deleted, then the VMA will fail checks such as https://chromium.googlesource.com/external/github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/+/refs/heads/master/include/vk_mem_alloc.h#12655

So it makes sense to adopt the strategy in this PR which will keep the allocator and Vulkan instance alive until all pending tasks have deleted their Vulkan objects.

autosubmit label was removed for flutter/flutter/166725, because - The status or check suite Google testing has failed. Please fix the issues identified (or deflake) before re-applying this label.