wgpu: Linux X11 Segfault on XCloseDisplay if PresentMode is Vsync

XCloseDisplay most of the time produces a segfault. This can be reproduced with the triangle example and with a personal test repo that’s using wgpu-rs i set up. Changing PresentMode to NoVsync fixes the segfault. The segfault only happens on Intel/AMD Mesa and apparently not on Nvidia Proprietary.

~~One tester using the Nvidia Proprietary driver also experienced fluctuating FPS with my test repo. LOG: https://pastebin.com/raw/UzRqcPpz (note the first FPS print is inaccurate)~~ (Unrelated)

About this issue

Original URL
State: open
Created 5 years ago
Comments: 16 (6 by maintainers)

Most upvoted comments

Note that’s the only known issue when using current NV drivers. There may be other unrelated or related bugs in other drivers, or in older NV drivers, as it took a while for us to work all these teardown issues out of our stack.

cubanismo on Sep 15, 2021

I can reproduce it again (on wgpu-native’s triangle example, like 20% of the time, Mesa/AMD on Arch Linux)! The call stack references line 267, which contains the call to glfwTerminate().

I’m pretty sure this same, or at least closely related, previously mentioned bug was also present in the Vulkan Cube Demos. The official fix looked like this: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/commit/0017308648b6bf8eef10ef0ffb9470576c0c2e9e.

In the cube demos, destroy the instance after closing the display system connection. It is possible for the driver to register callback functions with a library like Xlib. If the driver is unloaded when Xlib calls those callback functions, a segfault results.

The bug is explained in more detail here in https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1894#issuecomment-309832783.

http://www.xfree86.org/4.7.0/DRI11.html suggests that the (GL, but Vulkan here) can register a callback with Xlib. When the application calls XCloseDisplay, this callback is called and will segfault if the driver had already been unloaded, which could happen when the Vulkan instance is destroyed. Fix is to destroy the instance after cleaning up the display connection.

So, without the fix, this happenend.

vkDestroySurfaceKHR
vkDestroyInstance -> Driver unloads and registered callback functions would now accesses freed memory (if i understand correctly?).
glfwTerminate / XDestroyWindow -> Xlib calls the callback functions (if i understand correctly?).

The fix switches steps 2 and 3.

Now, the part i don’t understand is… does the wgpu-native triangle example ever do something that causes the driver to unload? Nothing stands out to me. So is this even the same bug? Need some help here, not an expert on these things.

Another thing, regarding the present mode… still can only reproduce it with Fifo? This is something to consider too.

Friz64 on Sep 7, 2021

I don’t remember the full ins and outs of this issue, but i think it’s perfectly fine to close (especially because there have been no other reports on this in this issue). I just tried both the hello-triangle example and (quickly updated) GLFW code and both seem to work flawlessly!

Thank you for this maintenance work btw 👍

Friz64 on Dec 1, 2020

Going to close this as gfx has changed a lot since this issue. If it’s still the case on wgpu master, feel free to re-open.

cwfitzgerald on Dec 1, 2020