Crash on Wayland WSI functions with multiple Vulkan instances (570.144 / 575.51.02)

Graphics / Linux Linux
1

Summary

If a second Vulkan instance creates its own Wayland surface and swapchain, then is torn down, subsequent WSI calls made by the first instance (vkAcquireNextImageKHR or vkQueuePresentKHR) seg-fault inside libnvidia-glcore.so. If the second instance never creates a swapchain, the first instance keeps working, so the trigger appears to be driver cleanup of Wayland-swapchain resources that are shared across instances.

Environment:

  • Operating System: Linux (Wayland session)
  • GPU: Nvidia GPU
  • Affected Nvidia Drivers: 570.144, 575.51.02 (crash observed within libnvidia-glcore.so) - Potentially others.
  • Windowing System: Wayland
  • API: Vulkan
  • Language/Bindings: Rust with ash (Vulkan bindings) and winit (windowing, using Wayland backend)

Reproduction steps

  1. Instance A
    • Create winit window A → Wayland surface A
    • Create Vulkan instance, device, swapchain A, etc.
  2. Instance B
    • Create winit window B → Wayland surface B
    • Create separate Vulkan instance, device, swapchain B (+ image views, semaphores).
  3. Tear down instance B
  4. Resume rendering with instance A and call
    • driver 575.* → vkAcquireNextImageKHR → seg-fault
    • driver 570.* → vkQueuePresentKHR → seg-fault

Minimal Reproducible Examples (MREs):

The following Rust code examples demonstrate the issue. Both examples likely trigger the same underlying driver bug, but it manifests in different WSI functions depending on the driver version.

MRE 1: Demonstrates Crash in vkAcquireNextImageKHR (Observed on Nvidia Driver 575.51.02)

MRE 2: Demonstrates Crash in vkQueuePresentKHR (Observed on Nvidia Driver 570.144)

Working Variation / Workaround (Avoids Segfault)

Dependencies (Cargo.toml) are the same for every MRE.

MRE.zip (13.2 KB)