Multiple leaks on Metal backend

[menduz]

Description
After carefully adding autoreleasepool to my unique thread's main loop, I figured that Metal is leaking around 1MB/s.

I've checked that other objects are being released as expected. And most of the Metal backend seems ok, giving the surface area of my engine vs the hotspots of allocations.

A very interesting finding, is that the reference count of the leaks is always 1. Using the env var flag OBJC_DEBUG_MISSING_POOLS=YES does not yield any warning (it does work though, I've set up a specific leak to test it).

Based on the code I'm reading from metal-rs, and giving the fact that upon allocation, all objects start with reference count 1. I'm thinking that maybe autoreleasepool is not enoug, and we shold be calling [command_encoder release] manually in the occurrences that are leaking.

Extra materials

Platform
wgpu-native, aarch64-macos, 0.19.3.1

[menduz]

After a good night sleep, and now, certainly angry about the entire day I lost to it. I figured that leaks were prefixed with NSZombie, which is a mechanism set by an environment variable NSZombiEnable=yes inherited from an XCode launch.

NSZombie is better explained at this gist. https://gist.github.com/JeOam/e62c95a0b4c21974bcf6

I can confirm that with proper autorelease pools, there are no apparent leaks.

[jonmmease]

Hi @menduz, I'm trying to understand a resource leak in a simple headless program with the metal backend over in #5529, and was thinking the process you went through here might be helpful in tracking that down. How did you generate the snapshot in your original post?

[menduz]

It was generated with a regular application profile in the Instruments.app

I solved all my leaks wrapping each iteration of my main loop in an autorelease pool

[teoxoy]

@menduz you shouldn't have to wrap things in autorelease pools. If there are leaks, we are not cleaning up resources and we should.

If you are still seeing leaks please open a new issue with a minimum reproducible example.