Resizing window leaks memory and slows down `queue.submit` calls

[Assasans]

Description
Calling surface.configure() on window resize leaks memory and slows down further queue.submit() calls. If surface.configure() is not called during resize, no memory leak occurs. This only happens with Vulkan backend, never with GL.

Repro steps
Start the hello_triangle example in debug mode. Begin rapidly resizing the window and observe the increase in process memory usage.

Expected vs observed behavior
Resizing the window for 6 minutes straight increased process memory usage from 163 MiB to 296 MiB.
Calling window.request_inner_size() each redraw with random size only leaked 5 MiB during 10 minutes (163 MiB -> 168 MiB).
Manually resizing the window in release mode leaks at much slower rate, similar to window.request_inner_size().

Expected: Memory usage should not grow unbounded during window resizes.

Extra materials
133 MiB leak: dhat trace: debug-manual-dhat-heap.json, wgpu trace: debug-manual-trace.zip.
5 MiB leak: dhat trace: debug-request_inner_size-dhat-heap.json, wgpu trace: debug-request_inner_size-trace.zip.

Platform
wgpu version: trunk, 04a3401
OS: Arch Linux, 6.15.2-zen1-1-zen, running Wayland KDE
CPU: AMD Ryzen 7 7700X
GPU: Radeon RX 7800 XT

[cwfitzgerald]

Does this happen if you turn off the Vulkan Validation Layers?

[Assasans]

Partially. The large leak and slowdown doesn't happen but small 4 MiB/5 minutes leak is still present.

debug-no_validation_layers-dhat-heap.json

[cwfitzgerald]

How are we supposed to interpret these files?

[Assasans]

It's a Valgrind's tool, you can use https://nnethercote.github.io/dh_view/dh_view.html or /usr/lib/valgrind/dh_view.html