[Audit][High] GPass extent not updated when SSAO creation fails during swapchain recreate, causing infinite loop

[MichaelFisher1997]

🔍 Module Scanned\n (automated audit scan)\n\n## 📝 Summary\nIn , when a swapchain resize triggers recreation of G-pass and SSAO resources, if fails after has already destroyed the old resources and created new ones, the is never updated. This means the size mismatch check will always trigger on subsequent frames, causing an infinite recreation loop.\n\n## 📍 Location\n- File: \n- Function/Scope: \n\n## 🔴 Severity: High\n- High: Infinite recreation loop causing performance degradation and potential GPU hang\n\n## 💥 Impact\nWhen a window resize occurs and is called, the following sequence happens:\n1. succeeds (updates )\n2. fails with an error\n3. The error is caught and logged, but still reflects the old size from before the failed SSAO creation\n4. On the next frame, sees the size mismatch and triggers another recreation attempt\n5. This loops indefinitely if SSAO keeps failing (e.g., due to memory pressure)\n\n## 🔎 Evidence\n\n\nThe issue is that after succeeds, should be updated to match the new size. But the code path for updating is inside itself, which may not run if the resources were already created earlier in the recreation chain.\n\nAlso, when fails, execution continues after the catch block but retains stale values, causing the mismatch check to re-trigger.\n\n## 🛠️ Proposed Fix\n1. After successful , explicitly set before the SSAO call\n2. If SSAO fails, still update to the current swapchain extent (even if not matching) so the mismatch check doesn't loop\n3. Add a flag or tracking mechanism to prevent recursive recreation attempts within the same frame\n\nExample fix:\n\n\n## ✅ Acceptance Criteria\n- [ ] No infinite loop occurs when fails\n- [ ] is correctly updated after successful resource creation\n- [ ] Error paths still allow the game to continue rendering (graceful degradation)\n- [ ] Verified with Zig 0.16.0 + SDL3 Dev Environment

Compiler: 0.16.0
assets/shaders/vulkan/ui.vert
assets/shaders/vulkan/depth_pyramid.comp
assets/shaders/vulkan/ui_tex.frag
assets/shaders/vulkan/taa.vert
assets/shaders/vulkan/water.frag
assets/shaders/vulkan/lpv_inject.comp
assets/shaders/vulkan/ui_tex.vert
assets/shaders/vulkan/terrain.frag
assets/shaders/vulkan/water.vert
assets/shaders/vulkan/terrain.vert
assets/shaders/vulkan/bloom_downsample.vert
assets/shaders/vulkan/bloom_upsample.vert
assets/shaders/vulkan/debug_shadow.vert
assets/shaders/vulkan/fxaa.vert
assets/shaders/vulkan/post_process.vert
assets/shaders/vulkan/shadow.vert
assets/shaders/vulkan/sky.vert
assets/shaders/vulkan/ssao.vert
assets/shaders/vulkan/taa.vert
assets/shaders/vulkan/terrain.vert
assets/shaders/vulkan/ui.vert
assets/shaders/vulkan/ui_tex.vert
assets/shaders/vulkan/water.vert
assets/shaders/vulkan/bloom_downsample.frag
assets/shaders/vulkan/bloom_upsample.frag
assets/shaders/vulkan/debug_shadow.frag
assets/shaders/vulkan/fxaa.frag
assets/shaders/vulkan/g_pass.frag
assets/shaders/vulkan/post_process.frag
assets/shaders/vulkan/shadow.frag
assets/shaders/vulkan/sky.frag
assets/shaders/vulkan/ssao.frag
assets/shaders/vulkan/ssao_blur.frag
assets/shaders/vulkan/taa.frag
assets/shaders/vulkan/terrain.frag
assets/shaders/vulkan/terrain_debug.frag
assets/shaders/vulkan/ui.frag
assets/shaders/vulkan/ui_tex.frag
assets/shaders/vulkan/water.frag
assets/shaders/vulkan/culling.comp
assets/shaders/vulkan/depth_pyramid.comp
assets/shaders/vulkan/lpv_inject.comp
assets/shaders/vulkan/lpv_propagate.comp
assets/shaders/vulkan/mesh.comp
assets/shaders/vulkan/culling.comp
assets/shaders/vulkan/ssao.frag
assets/shaders/vulkan/debug_shadow.frag
assets/shaders/vulkan/ssao_blur.frag
assets/shaders/vulkan/shadow.vert
assets/shaders/vulkan/mesh.comp
assets/shaders/vulkan/sky.frag
assets/shaders/vulkan/shadow.frag
assets/shaders/vulkan/ui.frag
assets/shaders/vulkan/g_pass.frag
assets/shaders/vulkan/sky.vert
assets/shaders/vulkan/taa.frag
assets/shaders/vulkan/ssao.vert
assets/shaders/vulkan/debug_shadow.vert
assets/shaders/vulkan/lpv_propagate.comp\n\n## 📚 References\n- Related code: in \n- Similar pattern: and are called together in multiple places\n

[github-actions]

Bug Classification: Bug (High severity - infinite loop)

Analysis

I traced the code flow in recreateSwapchainInternal (modules/engine-graphics/src/vulkan/rhi_frame_orchestration.zig:10-150):

1. Line 45: setup.createGPassResources(ctx) succeeds and sets ctx.gpass.g_pass_extent = extent at rhi_resource_setup.zig:350
2. Line 49: setup.createSSAOResources(ctx) fails with an error
3. Line 50-51: Error is caught, markSwapchainRecreateFailed() is called, function returns early
4. Line 149: markSwapchainRecreateSucceeded() is never called, so ctx.runtime.swapchain_recreate_failed remains true

Root Cause

The infinite loop occurs because:

• After createGPassResources succeeds, g_pass_extent IS correctly updated to the new extent
• After createSSAOResources fails, execution returns early without calling markSwapchainRecreateSucceeded()
• swapchain_recreate_failed stays true, but g_pass_extent is now correct (updated by the successful G-Pass creation)
• On the next frame, beginGPassInternal sees swapchain_recreate_failed=true and skips the mismatch check (line 153-154 in rhi_frame_orchestration.zig)
• However, if the recreation path is triggered again via recreateSwapchainInternal, the destroy functions are called again on already-destroyed resources, causing cascading failures

The issue description's claim that g_pass_extent isn't updated is technically incorrect based on the code at rhi_resource_setup.zig:350. The real bug is that swapchain_recreate_failed isn't properly cleared when we return early after partial success, causing subsequent frames to behave incorrectly.

Evidence Location

• rhi_frame_orchestration.zig:45-52 - The failure path that doesn't clear swapchain_recreate_failed
• rhi_resource_setup.zig:350 - Where g_pass_extent IS updated (after G-Pass creation succeeds)

Proposed Fix (from issue, with my validation)

1. The fix to update g_pass_extent before SSAO call is partially redundant since createGPassResources already does this
2. Key fix: When createSSAOResources fails after createGPassResources succeeds, still call markSwapchainRecreateSucceeded() or clear swapchain_recreate_failed to prevent stale state
3. Add protection against recursive recreation within same frame by checking swapchain_recreate_failed at the start of recreateSwapchainInternal

Example fix for rhi_frame_orchestration.zig:

setup.createGPassResources(ctx) catch |err| {
    _ = markSwapchainRecreateFailed(ctx, "G-Pass resources", err);
    return;
};
// Ensure extent is synced even if SSAO fails
ctx.gpass.g_pass_extent = ctx.swapchain.getExtent();

setup.createSSAOResources(ctx) catch |err| {
    _ = markSwapchainRecreateFailed(ctx, "SSAO resources", err);
    // Don't return early - fall through to mark success, extent is already synced
};

The acceptance criteria are reasonable: no infinite loop, correct extent update, graceful degradation. This bug would manifest under memory pressure causing repeated SSAO allocation failures during window resize.

opencode session  |  github run