Open bangnoise opened 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
?
The second process is a new VkInstance
@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 / @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.
@bangnoise Could you confirm that the application uses two different windows processes as opposed to two threads inside a single process?
@artem-lunarg correct, these are two different Windows processes
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.
Environment:
Describe the Issue
When
VkImportMemoryWin32HandleInfoKHR.handle
has aVK_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 betweenVkMemoryAllocateInfo.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, callsvkGetMemoryWin32HandleKHR()
->0x1698
Process 2:DuplicateHandle(0x1698)
->0xdb4
Process 2: sends0xdb4
to Process 1 Process 1:vkAllocateMemory()
withVkImportMemoryWin32HandleInfoKHR.handle
0xdb4
triggers false positive 3360 != 41760 but 3360 is the allocation of a previously deleted resource in Process 1