Discuss

• s&box editor 26.10.27c, Windows 10.0.26200, i5-8600K, RTX 3070 Ti (8 GB; device-local heap 8017 MiB), Vulkan.
• Editor play mode, single instance. The crash happened while a project script ran under the editor's tool interface, at 2026-11-01 08:05:27 local time.

• Project code issues a very large number of compute dispatches in a single frame. That code is a surface decal system: each paint call uploads structured GpuBuffer data (marks, bins, indices) and dispatches a compute shader into texture-array tiles.
• From 08:05:05 the log shows Grew the global bindless descriptor set ring 48 times in about 22 s, from 19 sets to 479, including Global bindless descriptor set ring reached 32 sets, something is submitting a lot per frame.
• Then a pooled vertex buffer allocation fails and the engine crashes inside its own logging call. The stack in the crash report is:
   GCHeap::Alloc ? g_pRenderDevice_CreateGPUBuffer ? CRenderDeviceVulkan::CreateGPUBuffer ? CreateGPUBufferFormatted ? CRenderContextVulkan::FillGPUBufferFormatted ? CVertexBufferVulkan::Allocate ? CMemoryManagerVulkan::AllocatePooled ? LoggingSystem_Log ? CLoggingSystem::LogDirect (access violation, write to 0x0).

vmaCreateBufferWithAlignment failed for '<unknown>' (vb pool): 7.91 MiB, alignment 16, memoryTypeBits 0x2, dedicated no;
  video memory VK_ERROR_OUT_OF_DEVICE_MEMORY (-2), system memory retry VK_ERROR_OUT_OF_DEVICE_MEMORY (-2)
  heap 0 (device local): driver 22939 MiB used of 6492 MiB budget, 8017 MiB heap; VMA 3948 blocks 22223 MiB holding 20531 allocations 22214 MiB
  heap 1 (host): driver 394 MiB used of 15580 MiB budget, 16348 MiB heap
  raw pools: vb 26 (26 MiB) ib 2 (2 MiB) cb 27 (54 MiB) staging 5 (40 MiB)
vmaCreateBufferWithAlignment failed fallback system memory allocation.  Fatal error: out of video and system memory.

1. The allocator ignores the budget for a long time. The driver reports 22.9 GB in use against a 6.5 GB budget on an 8 GB card, with 20,531 live allocations in 3,948 blocks, before anything fails. Our project keeps about 100 MB of surface textures alive. Our best guess, unconfirmed, is that a buffer data upload into a buffer still in use by a queued dispatch allocates a fresh copy every time, and nothing is freed until the frame finishes. Thousands of uploads in one frame then pile up.
2. The fatal path crashes in the logger. Instead of a clean "out of video memory" error, the process dies with an access violation writing to address 0 in CLoggingSystem::LogDirect. That may be the intended way a fatal error ends, but the crash report then names the logger instead of the memory error.
3. Related, probably a separate crash ID (08:09:19, same probe, fresh editor, only 3.3 GB in use). A vertex buffer pool request asked for 17592186043052.85 MiB, which is 264 bytes minus about 1.36 GiB. That looks like a negative 32-bit size widened to unsigned 64 bits. Our code only creates GpuBuffer<T> with an int element count that doubles as it grows. A count x stride that overflows a 32-bit int seems to reach Vulkan as an enormous request instead of being rejected with an exception.
4. Two more runs at 08:13:12 and 08:16:45 died the same way through vmaAllocateMemory (render target pool, 23.59 MiB, about 22.9 GB used of a 6.5 GB budget).