0
votes

Hello everyone.

I've got a problem here.

In Vulkan 1.2 when calling vkDestroyInstance the either VK_LAYER_KHRONOS_validation or VK_LAYER_LUNARG_standard_validation layers give me the following [annoying] output:

UNASSIGNED-ObjectTracker-ObjectLeak(ERROR / SPEC): msgNum: 0 - OBJ ERROR :
VK_DEBUG_REPORT_OBJECT_TYPE_DEVICE_EXT object VkDevice 0x215e63ab750[] has not been destroyed. 

and

VUID-vkDestroyInstance-instance-00629(ERROR / SPEC): msgNum: 0 - OBJ ERROR :
For VkInstance 0x215e5fd6dd0[], VkSurfaceKHR 0x2aefa40000000001[] has not been destroyed. 

and so far and so forth.

The point is: I do destroy VkSurfaceKHR prior to destroying the instance and also I do destroy the device.

XISCALL Win32VkContext::~Win32VkContext() 
{
    ...
    vkDestroyInstance(mVkInstance, nullptr);
    ... // some non-vulkan code
}
XResult XISCALL Win32VkContext::Terminate() noexcept
{
    ...
    vkDestroySurfaceKHR(mVkInstance, mVkSurface, nullptr);
    ...
    if (mVkDevice != VK_NULL_HANDLE) {
        vkDeviceWaitIdle(mVkDevice);
        vkDestroyDevice(mVkDevice, nullptr);
    }
    ...
}

The Terminate function gets called(debugger can't lie=)) from outside layer a lot before the destructor...

If this is not a Vulkan bug so what can this be? I've googled like a lot but could not find anything what could've solved this issue...

Placing the vkDestroyInstance to the end of the Terminate function gives same results. Putting the thread to sleep also didn't help.

UPD: I thought it can also be the driver bug.

1
Don't add "solved" to the title. Press the green checkmark to the left of your answer to mark the problem as solved. - HolyBlackCat

1 Answers

0
votes

I found an answer to this question. The case was that the XVK_ASSERT macro did create 2 instances of instance and device...