Fix leak of the eager exportable VkSemaphore.

Exporting an exportable VkSemaphore doesn't implicitly destroy the
VkSemaphore object. So instead of Detach()ing the VkSemaphore when it is
first consumed, just let it go out of the scope and be destroyed with
RAII. This also fixes the RAII by not destroying the VkSemaphore
immediately and instead wait until it becomes unused.

Found by running dawn_end2end_tests with the VVLs.

Bug: chromium:1258986
Change-Id: I858839b3094eee0f575c07a8f18504680afb53e3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103024
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This commit is contained in:
Corentin Wallez 2022-09-20 17:02:32 +00:00 committed by Dawn LUCI CQ
parent 1d100e4270
commit eebb7d5e52
1 changed files with 2 additions and 9 deletions

View File

@ -57,17 +57,11 @@ class ScopedSignalSemaphore : public NonMovable {
: mDevice(device), mSemaphore(semaphore) {}
~ScopedSignalSemaphore() {
if (mSemaphore != VK_NULL_HANDLE) {
ASSERT(mDevice);
mDevice->fn.DestroySemaphore(mDevice->GetVkDevice(), mSemaphore, nullptr);
mDevice->GetFencedDeleter()->DeleteWhenUnused(mSemaphore);
}
}
VkSemaphore Get() { return mSemaphore; }
VkSemaphore Detach() {
VkSemaphore semaphore = mSemaphore;
mSemaphore = VK_NULL_HANDLE;
return semaphore;
}
VkSemaphore* InitializeInto() { return &mSemaphore; }
private:
@ -357,8 +351,7 @@ MaybeError Device::SubmitPendingCommands() {
ExternalSemaphoreHandle semaphoreHandle;
DAWN_TRY_ASSIGN(semaphoreHandle,
mExternalSemaphoreService->ExportSemaphore(scopedSignalSemaphore.Get()));
// The ownership of signal semaphore has been transferred, we no longer need to track it.
scopedSignalSemaphore.Detach();
// Update all external textures, eagerly transitioned in the submit, with the exported
// handle, and the duplicated handles.
bool first = true;