Closed Scrumplex closed 7 months ago
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.
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
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?
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.
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
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.
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?
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.
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.
If optimizations play a role, that generally smells like (Rust) UB. Most commonly a UAF.
Did it work? It's a bit of a footgun that everything ash is Copy
, since these UAFs are so easy to do unwittingly.
Waiting for @Scrumplex to confirm. For me it never segfaults, so testing has been a bit of a pain.
@marc0246 that seems to have done the trick. thanks for the truckful of wisdom, i am eternally grateful.
That's great to hear!
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.
Template
If you dont understand something just leave it. If you can provide more detailed information than the template allows for, please ignore the template and present all of your findings.
main.rs
file that demonstrates the issue: TODOIssue
I and other users are experiencing segfaults when trying to run release builds of https://github.com/galister/wlx-overlay-s on AMD GPUs on Mesa 23.3.3 or Mesa 24.0.0.
Interestingly, it works fine with debug builds.
For Mesa 23.3.3 the segmentation fault occurs in
vk_common_QueueSubmit (_queue=0x0, submitCount=1, pSubmits=0x7ffffafd5ce0, fence=0x0) at ../src/vulkan/runtime/vk_synchronization2.c:294
(mesa source) which shows that the queue handle is apparently0x0
.After adding a simple debug message to wlx-overlay-s, we can confirm this difference in behavior between debug and release buids:
Debug:
Release with debug info:
Cargo.toml:
Backtrace for
cargo build --release
using stripped Mesa 23.3.3: