vkDestroySwapchainKHR crash with Direct Display on 415.18 on Linux with Fedora

Hello, I am seeing a crash in libnvidia-glcore.so.415.18 when attempting to destroy the swapchain via vkDestroySwapchainKHR while using direct display via vkAcquireXlibDisplayEXT. I’m able to run nearly the same code with the exception of surface creation when running with/without direct display (vkCreateDisplayPlaneSurfaceKHR for direct display vs vkCreateXlibSurfaceKHR for X Window) and only have the crash when running with direct display. This crash is new as of 410 and 415 as I didn’t have this crash on 396.

The Vulkan validation layers that can be enabled with direct display do not report any errors (not all layers can be enabled as some report incorrect errors when acquiring the display directly).

Any help is appreciated.

$ uname -a
Linux 4.18.16-200.fc28.x86_64 #1 SMP Sat Oct 20 23:53:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ nvidia-smi
±----------------------------------------------------------------------------+
| NVIDIA-SMI 415.25 Driver Version: 415.18 CUDA Version: 10.0 |
|-------------------------------±---------------------±---------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 1080 Off | 00000000:01:00.0 On | N/A |
| 27% 38C P8 11W / 180W | 1051MiB / 8116MiB | 1% Default |
±------------------------------±---------------------±---------------------+

±----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 8604 G /usr/libexec/Xorg 42MiB |
| 0 8677 G /usr/bin/gnome-shell 65MiB |
| 0 9042 G /usr/libexec/Xorg 268MiB |
| 0 9149 G /usr/bin/gnome-shell 457MiB |
| 0 10049 G …uest-channel-token=12939038777760331797 214MiB |
±----------------------------------------------------------------------------+

Hi,

I confirm this is a bug in our drivers. It will be fixed in the next release.

Was this actually fixed in 418.81 or is it expected to be fixed in the next release?

418.81 is the Windows release, the Linux release is 418.30 and does include the fix.

Thanks. It appears I posted in the wrong thread. I meant to post on this one, which may be related.