Memory leak on boids example

[Aultus-defora]

Description
Starting from MacOS Ventura, some Mac machines (there are Intel and M1 examples) using wgpu and apps using it accumulate memory over time.

Repro steps
With wgpu run cargo run --example boids --release; starting from v0.14; or cargo run --bin wgpu-examples boids --release on later versions. I tested trunk version too, so up to and including 0.19

Expected vs observed behavior
I expected old bevy apps to not accumulate memory after I updated MacOS. They do, as does even the wgpu boids example

Extra materials
Right when starting it has few memory usage:

After some time:

Platform
MacOS Sonoma 14.4 (23E214), Radeon Pro 560X 4 GB, memory 8 GB 2667 MHz DDR4.

[jonmmease]

Hi, I believe I'm seeing the same memory leak behavior on Sonoma 14.4.1 (23E224) with Apple M1 Pro. But in my case, the difference in memory usage happened when updating wgpu from 0.18.0 to 0.19.0 (and is still present in 0.19.3).

I have a test suite that performs headless rendering to PNG following https://sotrh.github.io/learn-wgpu/showcase/windowless/. And while tests are running the memory usage remained steady with wgpu 0.18.0, but rises steadily in 0.19.3, finally crashing with this backtrace:

Backtrace

assertion failed: !ptr.is_null()
thread 'test_image_baselines::test_image_baseline::case_118' panicked at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/foreign-types-shared-0.3.1/src/lib.rs:72:9:
assertion failed: !ptr.is_null()
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:144:5
   3: foreign_types_shared::ForeignTypeRef::from_ptr
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/foreign-types-shared-0.3.1/src/lib.rs:72:9
   4: <metal::commandqueue::CommandQueue as core::ops::deref::Deref>::deref
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/metal-0.27.0/src/commandqueue.rs:13:1
   5: wgpu_hal::metal::command::<impl wgpu_hal::CommandEncoder<wgpu_hal::metal::Api> for wgpu_hal::metal::CommandEncoder>::begin_encoding::{{closure}}
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-hal-0.19.3/src/metal/command.rs:179:17
   6: objc::rc::autorelease::autoreleasepool
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/rc/autorelease.rs:29:5
   7: wgpu_hal::metal::command::<impl wgpu_hal::CommandEncoder<wgpu_hal::metal::Api> for wgpu_hal::metal::CommandEncoder>::begin_encoding
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-hal-0.19.3/src/metal/command.rs:175:19
   8: wgpu_core::device::queue::PendingWrites<A>::activate
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.19.3/src/device/queue.rs:265:17
   9: wgpu_core::device::resource::Device<A>::new
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.19.3/src/device/resource.rs:230:9
  10: wgpu_core::instance::Adapter<A>::create_device_and_queue_from_hal
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.19.3/src/instance.rs:306:29
  11: wgpu_core::instance::Adapter<A>::create_device_and_queue
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.19.3/src/instance.rs:381:9
  12: wgpu_core::instance::<impl wgpu_core::global::Global<G>>::adapter_request_device
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.19.3/src/instance.rs:1084:23
  13: <wgpu::backend::wgpu_core::ContextWgpuCore as wgpu::context::Context>::adapter_request_device
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/backend/wgpu_core.rs:587:44
  14: <T as wgpu::context::DynContext>::adapter_request_device
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/context.rs:2019:22
  15: wgpu::Adapter::request_device
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/lib.rs:2118:22
  16: avenger_wgpu::canvas::request_wgpu_device::{{closure}}
             at ./src/canvas.rs:360:8
  17: avenger_wgpu::canvas::PngCanvas::new::{{closure}}::{{closure}}
             at ./src/canvas.rs:635:61
  18: avenger_wgpu::canvas::PngCanvas::new::{{closure}}
             at ./src/canvas.rs:631:5
  19: pollster::block_on
             at /Users/jonmmease/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pollster-0.3.0/src/lib.rs:128:15
  20: test_image_baselines::test_image_baselines::test_image_baseline
             at ./tests/test_image_baselines.rs:217:30
  21: test_image_baselines::test_image_baselines::test_image_baseline::case_118
             at ./tests/test_image_baselines.rs:29:5
  22: test_image_baselines::test_image_baselines::test_image_baseline::case_118::{{closure}}
             at ./tests/test_image_baselines.rs:184:7
  23: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  24: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5

I'm happy to open a new issue if this doesn't sound like the same issue.

Is the boids example that @Aultus-defora demonstrated above a sufficient repro to debug this? Is there anything else that would be helpful from our side? Thanks!

[jonmmease]

Since it may be a different problem, I created a dedicate repro for the issue I'm seeing in #5529

[teoxoy]

I managed to reproduce this on d3d12 as well, I'm seeing a ~1MB/min leak on boids.

[teoxoy]

This has been fixed by ddff69b (#5141).

git bisect start '--term-new=fixed' '--term-old=unfixed'
# status: waiting for both good and bad commits
# fixed: [7c51bb4a1317e9b509ddc75e3e13e0fa118004c9] Introduce `hlsl-out-if-target-windows` feature to Naga
git bisect fixed 7c51bb4a1317e9b509ddc75e3e13e0fa118004c9
# status: waiting for good commit(s), bad commit known
# unfixed: [152a94bc6c502226d9871f28e35db0b755ea35bf] suspect all the future suspects (#5413)
git bisect unfixed 152a94bc6c502226d9871f28e35db0b755ea35bf
# unfixed: [eb69c5fd2f4e0cce42d34c740485d360780d11a5] [types]: Make `Maintain` implement `Debug`. (#5802)
git bisect unfixed eb69c5fd2f4e0cce42d34c740485d360780d11a5
# fixed: [ebb930e9fdc20c3d2dcc3dbab8d0508cddd31acb] add more fields to `State` and cleanup fn params
git bisect fixed ebb930e9fdc20c3d2dcc3dbab8d0508cddd31acb
# unfixed: [29aa68e9a3843e0fcc84da7f137390a326f32882] [naga dot-out] Use `Handle::write_prefixed` instead of `index`.
git bisect unfixed 29aa68e9a3843e0fcc84da7f137390a326f32882
# fixed: [43f390e86f11bc8e949806525f11f4411df1bbba] [naga] Use `HandleSet` in `Validator::valid_expression_set`.
git bisect fixed 43f390e86f11bc8e949806525f11f4411df1bbba
# unfixed: [afc8e38fc13ae462bd65914eebb468526c4e6a0b] [naga] Use `HandleVec` in `Layouter`.
git bisect unfixed afc8e38fc13ae462bd65914eebb468526c4e6a0b
# fixed: [3e20909ade241d67a756003cf8790a3a663b201e] [naga] Use `Range::from_index_range` in `Arena::range_from`.
git bisect fixed 3e20909ade241d67a756003cf8790a3a663b201e
# fixed: [ddff69ba216ec29d87f86499446f1d63d732cfb5] Avoid leaking submitted command encoders (#5141)
git bisect fixed ddff69ba216ec29d87f86499446f1d63d732cfb5
# unfixed: [355613342e68efbab1ae96eb497941dbe6b6aa68] [naga] Add `packed` as a keyword for GLSL
git bisect unfixed 355613342e68efbab1ae96eb497941dbe6b6aa68
# first fixed commit: [ddff69ba216ec29d87f86499446f1d63d732cfb5] Avoid leaking submitted command encoders (#5141)