Wgpu: Segfault on Linux/Vulkan when closing application

[alichay]

When calling glfwTerminate() on a program that has, at some point, called wgpu_swap_chain_present(), there is a chance that the program will segfault in XCloseDisplay().

This is the minimum required to reproduce this error. You may have to run the program a couple times, this seems to be a bit random.
https://gist.github.com/alichay/cbfd952378065c8a445d494e0da6a033

[GabrielMajeri]

I've managed to reproduce this bug under Valgrind:

==45303== Invalid free() / delete / delete[] / realloc()
==45303==    at 0x483BD7B: realloc (vg_replace_malloc.c:836)
==45303==    by 0x52AE5EF: ??? (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x52AE688: xcb_get_extension_data (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x52AC1B0: xcb_send_request_with_fds64 (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x52AC6B9: xcb_send_request (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x5BC548A: xcb_present_pixmap (in /usr/lib/libxcb-present.so.0.0.0)
==45303==    by 0x6702D67: ??? (in /usr/lib/libvulkan_intel.so)
==45303==    by 0x6703366: ??? (in /usr/lib/libvulkan_intel.so)
==45303==    by 0x526C46E: start_thread (in /usr/lib/libpthread-2.31.so)
==45303==    by 0x4F0F3D2: clone (in /usr/lib/libc-2.31.so)
==45303==  Address 0x9288ba0 is 0 bytes inside a block of size 96 free'd
==45303==    at 0x483A9AB: free (vg_replace_malloc.c:540)
==45303==    by 0x52AB24F: xcb_disconnect (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x5141319: XCloseDisplay (in /usr/lib/libX11.so.6.3.0)
==45303==    by 0x48AE0BE: ??? (in /usr/lib/libglfw.so.3.3)
==45303==    by 0x48A504F: ??? (in /usr/lib/libglfw.so.3.3)
==45303==    by 0x109516: main (repro.c:108)
==45303==  Block was alloc'd at
==45303==    at 0x483BD7B: realloc (vg_replace_malloc.c:836)
==45303==    by 0x52AE5EF: ??? (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x52AE688: xcb_get_extension_data (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x52AC1B0: xcb_send_request_with_fds64 (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x52AC6B9: xcb_send_request (in /usr/lib/libxcb.so.1.1.0)
==45303==    by 0x5BC5177: xcb_present_query_version (in /usr/lib/libxcb-present.so.0.0.0)
==45303==    by 0x6701FD1: ??? (in /usr/lib/libvulkan_intel.so)
==45303==    by 0x67025C0: ??? (in /usr/lib/libvulkan_intel.so)
==45303==    by 0x4C94313: ash::vk::KhrSurfaceFn::get_physical_device_surface_support_khr (vk.rs:44511)
==45303==    by 0x4C9F8EE: ash::extensions::khr::surface::Surface::get_physical_device_surface_support (surface.rs:39)
==45303==    by 0x4C7BB28: <gfx_backend_vulkan::window::Surface as gfx_hal::window::Surface<gfx_backend_vulkan::Backend>>::supports_queue_family (window.rs:331)
==45303==    by 0x4B21531: wgpu_core::device::<impl wgpu_core::hub::Global<F>>::device_create_swap_chain (mod.rs:1867)

The crash comes from a realloc called from a thread which has been created by libvulkan_intel.so (I think?).

The memory was freed when main called glfwTerminate.

@alichay did this issue also happen to you on Intel, or did you reproduce it with a different GPU?

[alichay]

My gpu is an AMD Vega 56, so this seems to occur regardless of driver implementation.
This is what I get when I run the triangle example through valgrind.

==177904== Invalid read of size 8
==177904==    at 0x5ADDA0A: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5AE0B90: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5BAB5C7: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5BAE7E3: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5BAC3B5: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x516B3DF: ??? (in /usr/lib64/libvulkan.so.1.2.131)
==177904==    by 0x53B88A: ash::vk::KhrSwapchainFn::create_swapchain_khr (vk.rs:44899)
==177904==    by 0x59DD1E: ash::extensions::khr::swapchain::Swapchain::create_swapchain (swapchain.rs:76)
==177904==    by 0x89515C: gfx_backend_vulkan::device::<impl gfx_hal::device::Device<gfx_backend_vulkan::Backend> for gfx_backend_vulkan::Device>::create_swapchain (device.rs:2091)
==177904==    by 0x4DECCE: <gfx_backend_vulkan::window::Surface as gfx_hal::window::PresentationSurface<gfx_backend_vulkan::Backend>>::configure_swapchain (window.rs:448)
==177904==    by 0x6BA6E8: wgpu_core::device::<impl wgpu_core::hub::Global<F>>::device_create_swap_chain (mod.rs:1884)
==177904==    by 0x405B02: wgpu_device_create_swap_chain (device.rs:362)
==177904==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==177904== 
==177904== 
==177904== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==177904==  Access not within mapped region at address 0x8
==177904==    at 0x5ADDA0A: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5AE0B90: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5BAB5C7: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5BAE7E3: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x5BAC3B5: ??? (in /usr/lib64/libvulkan_radeon.so)
==177904==    by 0x516B3DF: ??? (in /usr/lib64/libvulkan.so.1.2.131)
==177904==    by 0x53B88A: ash::vk::KhrSwapchainFn::create_swapchain_khr (vk.rs:44899)
==177904==    by 0x59DD1E: ash::extensions::khr::swapchain::Swapchain::create_swapchain (swapchain.rs:76)
==177904==    by 0x89515C: gfx_backend_vulkan::device::<impl gfx_hal::device::Device<gfx_backend_vulkan::Backend> for gfx_backend_vulkan::Device>::create_swapchain (device.rs:2091)
==177904==    by 0x4DECCE: <gfx_backend_vulkan::window::Surface as gfx_hal::window::PresentationSurface<gfx_backend_vulkan::Backend>>::configure_swapchain (window.rs:448)
==177904==    by 0x6BA6E8: wgpu_core::device::<impl wgpu_core::hub::Global<F>>::device_create_swap_chain (mod.rs:1884)
==177904==    by 0x405B02: wgpu_device_create_swap_chain (device.rs:362)

[kvark]

I'm confused. Are we still talking about the application closure? The call stack attempts to create a new swapchain, which is certainly not expected on closing the app.

[alichay]

This was definitely on application close, although I didn't really know what I was doing with valgrind, so it's possible that it was showing some issue that had occurred earlier (?)

That said, I just downloaded the current master, and I can no longer replicate this issue, so I guess it's safe to close this issue under the assumption that the underlying issue has been resolved inadvertently through fixing something else. Thanks for your help!