Invalid queue handle on AMD GPUs using Mesa 23.3.3 and Mesa 24 about vulkano HOT 16 CLOSED

I see that vulkano's DeviceCreateInfo is missing the queues field, unlike your ash create info. That's against the safety contract of Device::from_handle, so that would be the first place I would look. Though I don't know why it would lead to such a strange outcome.

from vulkano.

I see that the safety contract of Instance::from_handle is violated for the same reason: the create infos must match.

I also see that you load the Vulkan library using both ash (Entry::load) and vulkano (VulkanLibrary::new()). That's going to result in 2 libraries being loaded, having different function pointers. You must instead only load the library on one side and pass the vkGetInstanceProcAddr function pointer when creating it on the other.

from vulkano.

Waiting for @Scrumplex to confirm.
For me it never segfaults, so testing has been a bit of a pain.

from vulkano.

Very strange. This would imply that when Vulkano calls vkGetDeviceQueue to construct a queue object, the Vulkan driver is returning zero as the handle. I wonder why.

from vulkano.

It should be noted that we use OpenXR here, which is also giving us a queue handle (https://github.com/galister/wlx-overlay-s/blob/81168644166c270e43ae559b18799fd36375216b/src/graphics.rs#L254)
I am just not sure if vulkano is supposed to allow this and let the driver cause a segfault though

from vulkano.

It is definitely not correct to create more than one Vulkano object from the same handle! Vulkano objects will always assume that they are the sole owner of their handles, and will not take into account things that happen outside of their control.

I did find a possible source of problems in Vulkano's current code, which I made #2466 for just now. Can you try out the Vulkano version in the PR and see if it fixes your issue?

from vulkano.

It should be noted that we use OpenXR here, which is also giving us a queue handle

OpenXR is not giving us a queue handle, OpenXR is giving us a VkDevice handle, which we pass into vulkano::device::Device::from_handle, which then creates the queue.

It's the same way as index_camera_passthrough does it, though I'm not sure if it's correct at all.

One notable mention from me is that not all users see a segfault, and those who see a segfault only see it on release builds.

from vulkano.

Building wlx-overlay-s with more conservative optimizations seems to work around this issue.

Adding the following to Cargo.toml:

[profile.release]
opt-level = 1

from vulkano.

If queues is empty when calling Device::from_handle, then the returned iterator of queues is also supposed to be empty. So then where is the OP getting Vulkano Queue objects from?

from vulkano.

Thanks so much for taking the time! I've fixed both the double-library issue as well as DeviceCreateInfo, but we're still seeing the same behavior of segfault with opt-level > 1.
I'm going to try and dig some more and let you know if I found something.

from vulkano.

If optimizations play a role, that generally smells like (Rust) UB. Most commonly a UAF.

from vulkano.

This is the UAF I think: https://github.com/galister/wlx-overlay-s/blob/800e4dd043b470fa3903ca8f5cec20468e284aa3/src/graphics.rs#L261

from vulkano.

Did it work? It's a bit of a footgun that everything ash is Copy, since these UAFs are so easy to do unwittingly.

from vulkano.

@marc0246 that seems to have done the trick. thanks for the truckful of wisdom, i am eternally grateful.

from vulkano.

That's great to hear!

from vulkano.

This is the UAF I think: galister/wlx-overlay-s@800e4dd/src/graphics.rs#L261

Errr, why is this a UAF?

Ooo, ash converts & into pointers internally!? Just throw away the lifetime. This is madness.

from vulkano.