Skip to content

vulkan/queue: Destroy wait temps if they are skipped

Benjamin Cheng requested to merge bcheng/mesa:main into main

Fixes a memory leak easily reproducible through vkcube:

==98499== 5,456 bytes in 341 blocks are definitely lost in loss record 1,831 of 1,836
==98499==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==98499==    by 0x563BD01: vk_default_alloc (vk_alloc.c:26)
==98499==    by 0x5200D7C: vk_alloc (vk_alloc.h:48)
==98499==    by 0x5201346: vk_sync_create (vk_sync.c:118)
==98499==    by 0x50D18EA: radv_create_sync_for_memory (radv_device.c:2972)
==98499==    by 0x51BBE76: wsi_common_acquire_next_image2 (wsi_common.c:841)
==98499==    by 0x51BBFA2: wsi_AcquireNextImage2KHR (wsi_common.c:874)
==98499==    by 0x51BBCD0: wsi_AcquireNextImageKHR (wsi_common.c:809)
==98499==    by 0x10CE2B: ??? (in /usr/bin/vkcube)
==98499==    by 0x4A4C30F: (below main) (in /usr/lib/libc.so.6)

Essentially vk_queue_submit_cleanup is supposed to go through the _wait_temps and destroy each one, but vk_queue_submit_final tries to prune the no-op waits from the list, meaning cleanup never sees the dummy sync (which is what radv_create_sync_for_memory creates). The solution in this patch is to destroy it when we prune it from the list.

Closes: #6223 (closed)

Merge request reports