False positive memory leaks in metal framework

[marvinh]

I am testing with the mac os tool “Leaks”

these consisitently show up as “leaks” in other frameworks as well

Just curious where its coming from.

Malloc 32 Bytes 1 0x60000051abe0 32 Bytes
MTLVertexDescriptorInternal 1 0x60000051aca0 32 Bytes
MTLVertexAttributeDescriptorInternal 1 0x60000051acc0 32 Bytes
MTLVertexAttributeDescriptorInternal 1 0x60000051ace0 32 Bytes
MTLVertexAttributeDescriptorInternal 1 0x60000051ad00 32 Bytes
MTLVertexAttributeDescriptorInternal 1 0x60000051ad20 32 Bytes
MTLVertexAttributeDescriptorInternal 1 0x60000051ad40 32 Bytes
MTLVertexAttributeDescriptorInternal 1 0x60000051ad60 32 Bytes
MTLVertexBufferLayoutDescriptorInternal 1 0x60000051ad80 32 Bytes
Malloc 32 Bytes 1 0x60000051af40 32 Bytes
Malloc 32 Bytes 1 0x600000539820 32 Bytes
Malloc 32 Bytes 1 0x6000005551c0 32 Bytes
juce::AsyncUpdater::AsyncUpdaterMessage 1 0x600000560ea0 32 Bytes

[daniel]

I guess this is still true:

AsyncUpdaterMessage leak issue!

Sometimes you have to lose a battle to win the war.

AsyncUpdaterMessage leak issue!

Very well put. Please don’t talk about this like it’s some kind of sloppy mistake. Obviously I hate leaky code, but in this case the only way to avoid it would involve a custom memory management layer for these message objects. Even if that could be made efficient, it adds unnecessary complexity and risks new bugs. So losing a tiny number of bytes when your DLL gets unloaded (maybe a couple of hundred bytes per run of the host) is the pragmatic option.

[marvinh]

Oh I meant the metal always leaks in apps I thought async updater might have still not finished running

[daniel]

Yeah, could be unrelated, IDK.
I just saw AsyncUpdater is mentioned in your log. And the leak size is coincidentally identical.