Who owns a Vulkan buffer after submission?

One release owner, named. Someone removes the entry once completion is known, and someone keeps it if the host operation exits early. Those may be the same component, but the design should say which. Setting the wrapper's local pointer to null changes that variable and nothing else. It frees nothing and says nothing about whether the submitted commands have finished.

Check where the retirement list itself lives. If it's allocated from per-frame scratch memory, it gets wiped at frame end while its buffers still wait on the GPU, and those buffers never get destroyed at all.

If the transfer is a move into the retirement list, the wrapper's move constructor has to leave the source owning nothing, so that its destructor does nothing. Usually that means writing VK_NULL_HANDLE into the moved-from object and checking for it in the destructor. Skip that and the local still destroys the buffer at scope exit, now with a second owner sitting in the list.

Moved-from objects are still destroyed. The standard's "valid but unspecified state" covers library types only. For your own wrapper, moved-from means whatever your move constructor writes, and nothing else.

darning was right about the moved-from object. My move constructor copied the handle and left the source holding it. With validation layers on, the moved-from local destroyed the buffer at scope exit and the layer reported VUID-vkDestroyBuffer-buffer-00922 on that call. Now it reads like this, and the report is gone.

Buffer(Buffer&& other) noexcept
    : device_(other.device_), buffer_(other.buffer_) {
  other.buffer_ = VK_NULL_HANDLE;
}

~Buffer() {
  if (buffer_ != VK_NULL_HANDLE)
    vkDestroyBuffer(device_, buffer_, nullptr);
}

The move happens in the frame owner, after the submit call returns success. The frame owner holds the fence for that submission. Each frame it calls vkGetFenceStatus on the oldest pending fence. VK_SUCCESS destroys that frame's entries. VK_NOT_READY keeps them. A failed submit never moves anything, so the local stays the single owner, which covers the early-exit case too.

Three things to check against that loop.

First, polling only the oldest fence is valid within one queue, because a fence signal from vkQueueSubmit covers every command earlier in submission order on that queue. If uploads go through a separate transfer queue, its fences say nothing about the graphics queue, and its entries need their own list.

Second, vkGetFenceStatus has a third outcome, VK_ERROR_DEVICE_LOST. With only VK_SUCCESS and VK_NOT_READY handled, a lost device either keeps the entries forever or lands in whichever branch the code treats as the default.

Third, at teardown nothing will be polled again. Call vkDeviceWaitIdle, drain the whole list, then destroy the device. Assert that the list is empty after the drain. It is one line and it catches the first entry that slips past the retirement path.

Uploads go through the graphics queue for now, so one list holds. A transfer queue would get its own list keyed by its own fences.

Device loss was the real gap. VK_ERROR_DEVICE_LOST from vkGetFenceStatus now leaves the poll loop and goes to teardown. A lost device never returns to a non-lost state, so polling again gains nothing. Teardown calls vkDeviceWaitIdle. On a lost device that call still returns in finite time, with VK_SUCCESS or VK_ERROR_DEVICE_LOST. The drain runs after it whatever it returns. Child object handles stay valid after the loss and must still be destroyed before the device, so both cases empty the list by the same path. The empty-list assertion sits right after the drain, where kiln put it.

The assertion needs one more decision. assert from <assert.h>, or <cassert> in C++, expands to nothing when NDEBUG is defined, and release configurations usually define it. In that build the check after the drain does not exist. If its purpose is to catch the first entry that escapes the retirement path, it should be an ordinary branch that reports the remaining count and is compiled in every configuration. An assert remains fine for the development build, provided nobody reads its silence in a release build as a passing check.