Commit 6fd1b13
committed
gfx/vulkan: fix VkDeviceMemory leak + spec violations in create/destroy paths
Four issues found in the same audit pass over gfx/drivers/vulkan.c, all
in the create-with-old / destroy-buffer ownership protocol. None of
them are the trigger for the iOS materialui content-close abort that
prompted the audit (the font teardown does not go through the patched
paths), but they are real and worth fixing on their own.
* vulkan_create_texture: VkDeviceMemory leak on alloc failure
(gfx/drivers/vulkan.c)
When called with a non-NULL `old`, the function destroys old's
view/image/buffer at the top of the `if (old)` block, then either
pilfers old->memory or allocates fresh memory for tex.memory. The
trailing `if (old)` cleanup is responsible for freeing old->memory in
the no-pilfer path (skipped by the pilfer branch via
old->memory = VK_NULL_HANDLE).
The vkAllocateMemory failure branch returns early before reaching
that cleanup. At return, old->view/image/buffer are dangling but
zeroed by the caller's `*old = tex` overwrite, while old->memory
still holds the original live VkDeviceMemory and is now unreachable.
Pure leak per failed call; reachable from every call site that
passes a real `old` (vk_per_frame texture realloc on resize, MUI/RGUI
set_texture, readback staging realloc).
Inline an equivalent cleanup before the early return: unmap if
mapped, free old->memory, zero old. Mirrors the unmap-before-free
the pilfer branch already does on line 1277.
* vulkan_create_texture: free-while-mapped on no-pilfer cleanup
(gfx/drivers/vulkan.c)
The trailing `if (old)` cleanup was calling vkFreeMemory on
old->memory without unmapping first, even though the pilfer branch a
few lines up does unmap. vkFreeMemory implicitly unmaps so this is
not a spec violation, but MoltenVK has historically handled
free-while-mapped poorly (KhronosGroup/MoltenVK#957) and the
asymmetry with the pilfer branch is gratuitous.
Add the `if (old->mapped) vkUnmapMemory(...)` guard before the free.
* vulkan_destroy_buffer: VUID-vkFreeMemory-memory-00677 violation
(gfx/drivers/vulkan.c)
Order was: vkUnmapMemory (unconditional) -> vkFreeMemory ->
vkDestroyBuffer. Two problems. First, the memory is freed while
buffer->buffer is still bound to it, which the spec forbids per
VUID-vkFreeMemory-memory-00677 -- vulkan_destroy_texture (line 974)
gets this right; this function was the outlier. Second,
vkUnmapMemory was unconditional, but vulkan_create_buffer leaves
buffer->mapped == NULL when its initial vkMapMemory fails, so a
destroy on a never-mapped buffer would unmap memory that is not
currently mapped.
Fix the order to unmap (gated on buffer->mapped) -> destroy buffer
-> free memory, with NULL-handle guards on the destroys for symmetry
with vulkan_destroy_texture.
* vulkan_init_quad_ibo: same VUID violation in vkMapMemory failure path
(gfx/drivers/vulkan.c)
Identical wrong order in the IBO-init map-failure cleanup -- frees
vk->quad_ibo.memory before destroying vk->quad_ibo.buffer that is
still bound to it. Swap the two calls. vulkan_deinit_quad_ibo
itself was already correct.1 parent 46ba4c1 commit 6fd1b13
1 file changed
Lines changed: 40 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1289 | 1289 | | |
1290 | 1290 | | |
1291 | 1291 | | |
| 1292 | + | |
| 1293 | + | |
| 1294 | + | |
| 1295 | + | |
| 1296 | + | |
| 1297 | + | |
| 1298 | + | |
| 1299 | + | |
| 1300 | + | |
| 1301 | + | |
| 1302 | + | |
| 1303 | + | |
| 1304 | + | |
| 1305 | + | |
1292 | 1306 | | |
1293 | 1307 | | |
1294 | 1308 | | |
| |||
1299 | 1313 | | |
1300 | 1314 | | |
1301 | 1315 | | |
| 1316 | + | |
| 1317 | + | |
| 1318 | + | |
| 1319 | + | |
| 1320 | + | |
| 1321 | + | |
1302 | 1322 | | |
| 1323 | + | |
| 1324 | + | |
| 1325 | + | |
1303 | 1326 | | |
| 1327 | + | |
1304 | 1328 | | |
1305 | 1329 | | |
1306 | 1330 | | |
| |||
3867 | 3891 | | |
3868 | 3892 | | |
3869 | 3893 | | |
3870 | | - | |
3871 | | - | |
| 3894 | + | |
| 3895 | + | |
| 3896 | + | |
| 3897 | + | |
| 3898 | + | |
| 3899 | + | |
| 3900 | + | |
| 3901 | + | |
3872 | 3902 | | |
3873 | | - | |
| 3903 | + | |
| 3904 | + | |
| 3905 | + | |
| 3906 | + | |
| 3907 | + | |
3874 | 3908 | | |
3875 | 3909 | | |
3876 | 3910 | | |
| |||
4483 | 4517 | | |
4484 | 4518 | | |
4485 | 4519 | | |
4486 | | - | |
| 4520 | + | |
| 4521 | + | |
4487 | 4522 | | |
| 4523 | + | |
4488 | 4524 | | |
4489 | 4525 | | |
4490 | 4526 | | |
| |||
0 commit comments