Closed jerry411 closed 2 months ago
You're right, this looks like a bug!
@Agrael1 Would you please have a look at this issue?
That is weird, SharedCommandBuffer should not have constructor with handle and device, it should have handle, device and pool only. I will check it ASAP
Ok, so the solution is actually quite interesting here:
SharedCommandPool
is the mandatory argument here, but only if you have everything set up correctly.
If the argument is absent, the destruction will not happen, but this is still valid, since those objects are destroyed when the pool is destroyed. I will replace the assertion with if-statement. Thanks for noticing!
Fixed by #1925
SharedCommandBuffer
can be created using standard way as most shared handles (with 2 parameters: standard handle +SharedDevice
as owner).But in case of
SharedCommandBuffer
with just these 2 parameters,PoolFreeShared() = default;
on line 399 in vulkan_shared.hpp is called. This causesm_destroy
andm_dispatch
properties being set tonullptr
. Later, whendestroy
method is called (line 410 in vulkan_shared.hpp),VULKAN_HPP_ASSERT( m_destroy && m_dispatch );
obviously fails.The second constructor (
PoolFreeShared
on line 402) which correctly sets bothm_destroy
andm_dispatch
is called only whenSharedCommandBuffer
constructor is called with additional parameter (SharedCommandPool
) after owner (SharedDevice
).This looks like a bug. Either constructor without
SharedCommandPool
parameter should not exist (because it will always cause assertion fail on destroy), or that assertion indestroy
method should be adjusted to accommodate this possibility.