lavapipe leaks introduced in eb7eccc7
lavapipe use to be leak free. I happened to notice that's no longer the case now.
Commit eb7eccc7 introduced a leak of the lvp_descriptor_set_layout
pointer array.
This fixes it:
diff --git a/src/gallium/frontends/lavapipe/lvp_execute.c b/src/gallium/frontends/lavapipe/lvp_execute.c
index 0c0b1c8adf3..66689a113d5 100644
--- a/src/gallium/frontends/lavapipe/lvp_execute.c
+++ b/src/gallium/frontends/lavapipe/lvp_execute.c
@@ -3870,6 +3870,7 @@ static void lvp_execute_cmd_buffer(struct lvp_cmd_buffer *cmd_buffer,
break;
case VK_CMD_BIND_DESCRIPTOR_SETS:
handle_descriptor_sets(cmd, state);
+ vk_free(cmd_buffer->queue.alloc, cmd->driver_data);
break;
case VK_CMD_BIND_INDEX_BUFFER:
handle_index_buffer(cmd, state);
However, this commit introduces a dozen of other vk_zalloc
calls, with no obvious corresponding vk_free
calls added. I don't see how this is supposed to work.
@zmike, @airlied: I'd add vk_alloc/vk_zalloc
/ vk_free
balance to the checklist of things reviewers should watch for.
@sroland, there's a bunch of other unrelated lavapipe leaks. At this moment it's not urgent for us (VMware) to address these leaks, so I'm inclined to run our tests with AddressSanitizer enabled, but disable LeakSanitizer for now, and enable if/when leaks really becoming pressing matter. If/when this happens, I think we need to ensure there are some GitLab FDO tests in place with ASAN+LSAN to ensure leaks don't keep creeping back in.