[KhronosGroup > Vulkan-Samples > Swapchain Recreation] sample crashes synchronization validation layer on window resize

[Sanakan8472]

Environment:

• OS: Windows 11 23H2
• GPU and driver version: Nvidia 3060, ver: 552.22
• SDK or header version if building from repo: 1.3.283 built from source: bacc84e
• Options enabled: Used Vulkan Configurator and selected the synchronization preset, disabled debug break.

Describe the Issue

1. Enable synchronization preset in Vulkan Configurator and disabled debug break.
2. Checkout db55e980ecb994f5cfa769954b2a812d8f9bc235 (top of main as of writing) of Vulkan-Samples and start the Swapchain Recreation sample via: vulkan_samples sample swapchain_recreation.
3. Resize the sample window by grabbing a corner and wiggling the mouse for 10 seconds.
4. Observe the following error in the log:

[error] 1567320034 - UNASSIGNED-Threading-Info: Validation Error: [ UNASSIGNED-Threading-Info ] Object 0: handle = 0x15784b58af0, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5d6b67e2 | vkDestroySwapchainKHR():  Couldn't find VkImage Object 0x15784b58af0. This should not happen and may indicate a bug in the application.

6. Letting go of the left mouse button causes either a different error or crashes the validation layer (callstack at the bottom):

[error] 1123218669 - SYNC-HAZARD-WRITE-AFTER-PRESENT: Validation Error: [ SYNC-HAZARD-WRITE-AFTER-PRESENT ] Object 0: handle = 0x157fcee9b20, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x42f2f4ed | vkQueueSubmit():  Hazard WRITE_AFTER_PRESENT for entry 0, VkCommandBuffer 0x1578a2e24e0[], Submitted access info (submitted_usage: SYNC_IMAGE_LAYOUT_TRANSITION, command: vkCmdBeginRenderPass, seq_no: 1, renderpass: VkRenderPass 0x15785b30ca0[], reset_no: 77). Access info (prior_usage: SYNC_PRESENT_ENGINE_SYNCVAL_PRESENT_PRESENTED_SYNCVAL, write_barriers: 0, queue: VkQueue 0x157fcee9b20[], submit: 149, batch: 0, batch_tag: 675, vkQueuePresentKHR present_tag:675, pSwapchains[0]: VkSwapchainKHR 0x1578a116d30[], image_index: 1image: VkImage 0x15784d46f40[] (destroyed)).

Expected behavior

I would expect no validation issues on the official samples as the window is resized. I'm not sure if this is a sample problem or a validation layer problem, but as the validation layer crashes, I thought I'd start here.

Note that it doesn't always crash, it looks like it is more likely to crash the longer I resize the window.

Additional context

code or terminal output

Crash: 
**Exception thrown: read access violation.
image_state._Ptr was nullptr.**

>	[Inline Frame] VkLayer_khronos_validation.dll!vvl::Image::HasAHBFormat() Line 139	C++
 	VkLayer_khronos_validation.dll!ValidationStateTracker::PostCallRecordCreateImageView(VkDevice_T * device, const VkImageViewCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkImageView_T * * pView, const RecordObject & record_obj) Line 451	C++
 	VkLayer_khronos_validation.dll!vulkan_layer_chassis::CreateImageView(VkDevice_T * device, const VkImageViewCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkImageView_T * * pView) Line 2319	C++
 	vulkan-1.dll!00007ffc09229a5d()	Unknown
 	vulkan_samples.exe!SwapchainRecreation::init_swapchain_image(unsigned int index) Line 355	C++
 	vulkan_samples.exe!SwapchainRecreation::acquire_next_image(unsigned int * index) Line 592	C++
 	vulkan_samples.exe!SwapchainRecreation::update(float delta_time) Line 1057	C++
 	vulkan_samples.exe!vkb::Platform::update() Line 266	C++
 	vulkan_samples.exe!vkb::Platform::main_loop() Line 218	C++
 	vulkan_samples.exe!platform_main(const vkb::PlatformContext & context) Line 67	C++
 	vulkan_samples.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 43	C++
 	vulkan_samples.exe!invoke_main() Line 107	C++

[artem-lunarg]

@Sanakan8472 thanks for the report. I'm trying to reproduce the issue. Was the "Handle Wrapping" option enabled in Vulkan Configurator ? Also, if you can provide the following, this might be helpful: monitor refresh rate, CPU core count. I'm asking this because threading issues are tricky to reproduce. I found one issue when handle wrapping is disabled, but it might be a different one than what is reported here (I have not managed to get UNASSIGNED-Threading-Info error yet).

[Sanakan8472]

@artem-lunarg my appologies, I had "Handle Wrapping" disabled as you suspected. I installed the SDK in a VM just to double check that the option is on by default and it is, so I must have disabled it by accident. Sorry about that.
I can't reproduce the crash when "Handle Wrapping" is enabled.
Just for completeness, I run at 60hz with 20 cores.

[artem-lunarg]

@Sanakan8472 My assumption that it should work with "Handle Wrapping" disabled too, I will investigate this, it might be a real issue. Enabling this option might be a good workaround (it is also a good default for development).

[Sanakan8472]

Thanks for the help @artem-lunarg , I'll leave the ticket open then.