[Audit][High] WorkerPool.init leaks pool struct on thread spawn failure after pool allocation succeeds

[MichaelFisher1997]

🔍 Module Scanned\n (automated audit scan)\n\n## 📝 Summary\nWhen successfully allocates the struct but fails during worker thread creation, the allocated pool struct is leaked because the is placed after the thread allocation , meaning it only fires if the thread array allocation fails, not if thread spawning fails.\n\n## 📍 Location\n- File: \n- Function/Scope: \n\n## 🔴 Severity: High\n- Critical: Crashes, data corruption, security vulnerabilities, GPU device loss\n- High: Memory leaks, race conditions, incorrect rendering, broken features\n- Medium: Performance degradation, missing error handling, suboptimal patterns\n- Low: Code style, dead code, minor improvements\n\n## 💥 Impact\nIf fails (e.g., due to system resource exhaustion, ulimit restrictions, or thread pool exhaustion), the struct allocated at line 308 will be leaked. The errdefer cleanup order means is NOT called on thread spawn failure—only fires if the thread array was allocated. This causes heap memory to leak each time thread spawning fails.\n\n## 🔎 Evidence\n\n\nThe fix requires adding after the thread array allocation succeeds but before the thread spawning loop, so that any thread spawn failure triggers cleanup of the already-allocated pool struct.\n\n## 🛠️ Proposed FixnAdd an immediately after the thread array allocation succeeds:\n\n\n\n## ✅ Acceptance Criteria\n- [ ] no longer leaks the pool struct when fails after pool allocation succeeds\n- [ ] The existing unit test still passes\n- [ ] Zig 0.16.0 + SDL3 Dev Environment

Compiler: 0.16.0
assets/shaders/vulkan/culling.comp
assets/shaders/vulkan/lpv_inject.comp
assets/shaders/vulkan/taa.vert
assets/shaders/vulkan/ui_tex.frag
assets/shaders/vulkan/sky.frag
assets/shaders/vulkan/water.frag
assets/shaders/vulkan/g_pass.frag
assets/shaders/vulkan/ui_tex.vert
assets/shaders/vulkan/terrain.vert
assets/shaders/vulkan/shadow.vert
assets/shaders/vulkan/depth_pyramid.comp
assets/shaders/vulkan/shadow.frag
assets/shaders/vulkan/debug_shadow.frag
assets/shaders/vulkan/lpv_propagate.comp
assets/shaders/vulkan/ssao_blur.frag
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/ssao.vert
assets/shaders/vulkan/sky.vert
assets/shaders/vulkan/mesh.comp
assets/shaders/vulkan/water.vert
assets/shaders/vulkan/debug_shadow.vert
assets/shaders/vulkan/ui.frag
assets/shaders/vulkan/ssao.frag
assets/shaders/vulkan/ui.vert
assets/shaders/vulkan/terrain.frag
assets/shaders/vulkan/taa.frag passes without errors\n\n## 📚 References\n- Zig errdefer behavior: "errdefer" in Zig executes when the function returns with an error from within the scope where the errdefer is defined\n- Related patterns in codebase: vs

[github-actions]

The audit report appears to be incorrect. Let me analyze the actual errdefer chain:

Current code at lines 308-335:

const pool = try allocator.create(WorkerPool);  // 308
errdefer allocator.destroy(pool);                 // 309 - fires last

const threads = try allocator.alloc(Thread, count);  // 311
errdefer allocator.free(threads);                    // 312 - fires second

// pool init at 314-319...

errdefer {                                          // 325-330 - fires first
    queue.stop();
    for (threads[0..pool.spawned_count]) |t| t.join();
}

for (threads) |*t| {
    t.* = try Thread.spawn(.{}, workerThread, .{ queue, pool });  // 333
    pool.spawned_count += 1;
}

On Thread.spawn failure, errdefer unwinding order is:

1. Lines 325-330: stop queue, join spawned threads
2. Line 312: allocator.free(threads)
3. Line 309: allocator.destroy(pool) ← pool IS cleaned up

The audit's claim that pool is leaked on thread spawn failure is factually incorrect. The errdefer allocator.destroy(pool) at line 309 remains active throughout and fires correctly on any error after its registration.

The audit appears to be a false positive from a tool that misread the errdefer execution order (LIFO - last registered, first executed).

Verdict: Not a bug. No action needed. The cleanup chain is correct.

opencode session  |  github run