KhronosGroup / Vulkan-ValidationLayers

Vulkan Validation Layers (VVL)
https://vulkan.lunarg.com/doc/sdk/latest/linux/khronos_validation_layer.html
Other
773 stars 406 forks source link

False positive vkAllocateMemory VUID-VkMemoryAllocateInfo-allocationSize-01743 #8874

Open bangnoise opened 4 days ago

bangnoise commented 4 days ago

Environment:

Describe the Issue

When VkImportMemoryWin32HandleInfoKHR.handle has a VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT from a second process which matches a previously created and closed handle from the validated process, the validation layer incorrectly reports a mismatch between VkMemoryAllocateInfo.allocationSize and the size when the payload was created.

Expected behavior

No validation error should be reported.

Valid Usage ID

Additional context

Process 1: allocates 3360 bytes, calls vkGetMemoryWin32HandleKHR() -> 0xdb4 Process 1: ... Process 1: CloseHandle(0xdb4), vkFreeMemory() Process 2: allocates 41760 bytes, calls vkGetMemoryWin32HandleKHR() -> 0x1698 Process 2: DuplicateHandle(0x1698) -> 0xdb4 Process 2: sends 0xdb4 to Process 1 Process 1: vkAllocateMemory() with VkImportMemoryWin32HandleInfoKHR.handle 0xdb4 triggers false positive 3360 != 41760 but 3360 is the allocation of a previously deleted resource in Process 1

ERROR : VALIDATION - Message Id Number: -1224652074 | Message Id Name: VUID-VkMemoryAllocateInfo-allocationSize-01743
    Validation Error: [ VUID-VkMemoryAllocateInfo-allocationSize-01743 ] | MessageID = 0xb7014ad6 | vkAllocateMemory(): pAllocateInfo->allocationSize allocationSize (125280) does not match pAllocateInfo->pNext<VkImportMemoryWin32HandleInfoKHR>.handle (0x15fc) of type VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT allocationSize (41760).
The Vulkan spec states: If the parameters define an import operation, the external handle was created by the Vulkan API, and the external handle type is VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT or VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT, then the values of allocationSize and memoryTypeIndex must match those specified when the payload being imported was created (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkMemoryAllocateInfo-allocationSize-01743)
spencer-lunarg commented 4 days ago

to be clear, when you say 2 processes here, are these the same VkInstance and VkDevice?

Or are you loading process one (which loads the validation layers) and process two is a whole new VkInstance?

bangnoise commented 4 days ago

The second process is a new VkInstance

spencer-lunarg commented 4 days ago

@charles-lunarg / @artem-lunarg do you know if on Windows, if you create 2 VkInstance on 2 different processes, would the loader DLL be loaded once or twice?

If it is loaded only once, I assume the issue is the state tracking is somehow not mapping the value correctly to the dispatch handle?

charles-lunarg commented 4 days ago

@charles-lunarg / @artem-lunarg do you know if on Windows, if you create 2 VkInstance on 2 different processes, would the loader DLL be loaded once or twice?

Twice, the VkInstance and all DLL's are per-process.

artem-lunarg commented 4 days ago

@bangnoise Could you confirm that the application uses two different windows processes as opposed to two threads inside a single process?

bangnoise commented 4 days ago

@artem-lunarg correct, these are two different Windows processes

bangnoise commented 1 day ago

We're getting false positives for VUID-VkMemoryDedicatedAllocateInfo-image-01876 too, and the underlying cause appears to be the same - erroneous entries in ValidationStateTracker::win32_handle_map_ from previously destroyed resources.