Segmentation fault on program termination with RAII Vulkan headers

[buuugle]

Hi!
I followed the new tutorial that uses RAII Vulkan headers. Everything works fine, but there is one problem: before the program terminates, when the HelloTriangleApplication instance is destroyed, all the vk::raii objects are destroyed after the glfwDestroyWindow and glfwTerminate calls, which creates a segmentation fault. To avoid this, I added this code to the cleanup function:

void cleanup() {
    inFlightFences.clear();
    renderSemaphores.clear();
    presentSemaphores.clear();
    commandBuffers.clear();
    commandPool = nullptr;
    pipeline = nullptr;
    pipelineLayout = nullptr;
    imageViews.clear();
    images.clear();
    swapChain = nullptr;
    surface = nullptr;
    queue = nullptr;
    device = nullptr;
    physicalDevice = nullptr;
    debugMessenger = nullptr;
    instance = nullptr;

    glfwDestroyWindow(window);
    window = nullptr;
    glfwTerminate();
}

This allows all destructors of Vulkan objects to be called before the GLFW window is destroyed.
I find this solution inconvenient because it completely kills the benefits of RAII.

Am I missing something in the tutorial?

[SaschaWillems]

This shouldn't be necessary. Can you add some detail? Like what IDE/compiler are you using? What does the call stack up to the seg fault look like?

[FabTheDog]

Hi,

I have the same issue running on Wayland, with gcc 15.2.1, I get a segfault when closing the window. The code ran is the one from the compute shader chapter. I ran the program in gdb and got the following info:

d35c01 in wl_map_insert_at (map=map@entry=0x5555555edd50, flags=flags@entry=1, i=<optimized out>, data=<optimized out>) at ../wayland-1.24.0/src/wayland-util.c:290
290             start[i].next |= (flags & 0x1) << 1;
(gdb) 
(gdb) bt
#0  0x00007ffff7d35c01 in wl_map_insert_at (map=map@entry=0x5555555edd50, flags=flags@entry=1, i=<optimized out>, data=<optimized out>) at ../wayland-1.24.0/src/wayland-util.c:290
#1  0x00007ffff7d35d81 in proxy_destroy (proxy=proxy@entry=0x55555646a830) at ../wayland-1.24.0/src/wayland-client.c:577
#2  0x00007ffff7d37032 in wl_proxy_destroy_caller_locks (proxy=0x55555646a830) at ../wayland-1.24.0/src/wayland-client.c:601
#3  wl_proxy_destroy (proxy=0x55555646a830) at ../wayland-1.24.0/src/wayland-client.c:624
#4  0x00007fff0e926289 in ?? () from /usr/lib/libnvidia-glcore.so.580.82.09
#5  0x00007fff0e91962f in ?? () from /usr/lib/libnvidia-glcore.so.580.82.09
#6  0x00007fff0e91ab9f in ?? () from /usr/lib/libnvidia-glcore.so.580.82.09
#7  0x00007fff0e965886 in ?? () from /usr/lib/libnvidia-glcore.so.580.82.09
#8  0x00007fff643fb43d in ?? () from /usr/lib/libVkLayer_khronos_validation.so
#9  0x00007fff647ac8e2 in ?? () from /usr/lib/libVkLayer_khronos_validation.so
#10 0x00005555555651c2 in ComputeShaderApplication::~ComputeShaderApplication() ()
#11 0x000055555555b1f8 in main ()

I hope this helps. I can give more info if needed.

[FabTheDog]

I think I found a minimal solution to avoid the segfault in the case described before. The issue comes from the swapchain not being cleaned up before the destructor of the app is called. Adding a call to cleanupSwapChain() in the mainloop after waiting for the device to be idle solves the issue. So the proposed solution is simply

    void mainLoop() {
        while (!glfwWindowShouldClose(window)) {
            glfwPollEvents();
            drawFrame();
            // We want to animate the particle system using the last frames time to get
            // smooth, frame-rate independent animation
            double currentTime = glfwGetTime();
            lastFrameTime      = (currentTime - lastTime) * 1000.0;
            lastTime           = currentTime;
        }

        device.waitIdle();
        // Add cleanup of SwapChain
        cleanupSwapChain();
    }

The call to cleanupSwapChain() could also be made in the cleanup function, but it would mean cleanup() wouldn't be const anymore.

[SaschaWillems]

Also brought up on the Khronos forums: https://community.khronos.org/t/vk-swapchainkhr-destructor-segfaults-on-tutorial-code/112394

@gpx1000 : I don't know enough about how the RAII headers work. Is this something we need to fix on our end?

[gpx1000]

... I actually am surprised by this. RAII ensures that the swapchain does in fact get cleaned up just by going out of scope. In fact the only way this makes sense is if the swapchain destructor is called after the program exits. That's not how RAII works. RAII has a very specific order for destruction that in inherit in the standard. It's the reverse of their construction order.
It goes Local Variable/objects destroy first, naturally when function or scope is exited. Next is the class destructor, which is called when a class is destroyed. Next is non-static member objects, and finally base class destructors in the reverse order of their inheritence heirarchy.
Everything is cleaned up before the program is returned to the operating system. It is a cleanly defined destruction and calling swapchain destruction early in that process makes no sense. maybe the validation layers have some context to the driver or something and that's keeping it open; but to directly answer your question, I would be surprised if we need to change any code. That just shouldn't be the way the C++ standard works and I think there's a bug that is deeper here than the tutorial.

[cynthsynth]

im getting the same segfault after closing window on wayland (mutter).
although i am interested in knowing why this segfault not caused on x11? just running with XDG_SESSION_TYPE=x11 ./vk-tutorial makes program close gracefully, and obv with a proper x11 session too,but fails in any wayland session.

also like the user buuugle, manually destructing just the surface object ( and therefore swapchain ) in cleanup seems to work for me too, and calling destructor seems fine since its only seems to set fields to nullptr, but idk.

// relevant program state is at https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.html
    void
    cleanup() {
        swapchain.~SwapchainKHR();
        surface.~SurfaceKHR();
        glfwDestroyWindow(window);
        glfwTerminate();
    }

and just for some extra info:
It's an amd machine, using iGpu.
Fedora 42
gcc (GCC) 15.2.1 20251211 (Red Hat 15.2.1-5)
DE: GNOME 48.7 (same segfault on hyprland & kde too though)
CPU: AMD Ryzen 5 5500U
GPU: AMD Lucienne [Integrated]
WM: Mutter (Wayland)
Linux 6.17.12-200.fc42.x86_64

some relevant things from vulkaninfo --summary

Vulkan Instance Version: 1.4.328
...
GPU0:
        apiVersion         = 1.4.311
        driverVersion      = 25.1.9
        deviceType         = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
        driverInfo         = Mesa 25.1.9
        conformanceVersion = 1.4.0.0

[gpx1000]

Wayland... hmm... odd, usually that means that GLFW is having issues. Lemme fire up Wayland here and see if I can track this down.

[cynthsynth]

im a novice at all this, so apologies if this is adding nothing but regardless,

[1] On wayland, closing causes segfault,

[1]    390551 segmentation fault (core dumped)  XDG_SESSION_TYPE=wayland ./vk-tut

with the backtrace showing it being happening in ~SwapchainKHR destructor.
full backtrace at https://pastebin.com/s75ncHbT

[2] On X11, while i don't get segfault on closing using the window close button, if i force close using Alt+F4 i get a double free,

free(): double free detected in tcache 2
[1]    392625 IOT instruction (core dumped)  XDG_SESSION_TYPE=x11 ./vk-tut

which happens on ~SwapchainKHR dtor too. Full backtrace at https://pastebin.com/CJPk9SsB
So, it may not be 100% correctly working?

Just to make sure i ran code from the chapter 05 uniform buffer chapter and it still gives me issue [1] and [2]

Now if i simply remove glfwTerminate() from cleanup() and just let the os clean it up after program ends, or make sure it happens after the app instance is destroyed like

    {
        HelloTriangleApplication app;
        try {...} catch (...)  {...}
    }
    glfwTerminate();

then both issues [1] and [2] don't occur, idk why terminating glfw before cleaning up all vulkan things causes issues, but this seems to fix them, and specifically in glfwTerminate(), if i comment out the platform specific functions in glfw to close server connection which is this line

    _glfw.platform.terminate();

(gh-link) which calls the appropriate wayland and x11 functions.
then also [1] and [2] don't occur, so i guess don't terminate display connections till vulkan stuff is clear? specifically the surface and therefore swapchain since problem seems to happen there but im dumb so maybe theres some other reason

[gpx1000]

Absolutely excellent diagnosis. I'm currently away from my computer due to holiday being out and about. But, we should do two things:

• Ensure all deletes within the destructor are guarded against being called more than once
• Investigate again if the glfw has addressed Wayland reentrant calls to terminate and init. Init implicitly sets up terminate and we addressed this in samples by guard (checking if device is valid before deleting anything). It's a clunky solution but likely best practice.

Happy new years and thanks for reporting and the excellent investigation!

[cynthsynth]

Happy new years and thanks for reporting and the excellent investigation!

Cheers! thanks and happy new years

[Raffaello]

the vulkan with raii should be encapsulated in a master object that it must be going out of scope before terminating the GLFW (or whatever else)

as one possible solution:
this could be simply achieved creating that object inside the main try/catch block and the GLFW init terminate outside the try catch.

kindof:

glfwInit();
try{
 HelloTriangleApplication app;
// ....
} catch(...) {
// ...
}

glfwTerminate();

[I-OCode]

I'm a passerby here. My two cents: Wayland doesn't like it when you destroy the swapchain (or the surface) after the window's destroyed, which makes sense. I'd say it'd make more sense to destroy the swapchain first, and then the window. To do this you could do what @Raffaello did, but why not use vkfw instead? Then the code's more modern.