# False positive memory leaks in metal framework

**URL:** <https://forum.juce.com/t/false-positive-memory-leaks-in-metal-framework/69446>\
**Category:** MacOSX and iOS\
**Created:** [September 7, 2026, 5:10pm UTC](https://forum.juce.com/t/false-positive-memory-leaks-in-metal-framework/69446 "2026-09-07T17:10:50Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![marvinh](https://avatars.discourse-cdn.com/v4/letter/m/35a633/32.png) [@marvinh](https://forum.juce.com/u/marvinh)\
**Post date:** [September 7, 2026, 5:10pm UTC](https://forum.juce.com/t/false-positive-memory-leaks-in-metal-framework/69446/1 "2026-09-07T17:10:50Z")

</div>

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`

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [September 8, 2026, 8:54am UTC](https://forum.juce.com/t/false-positive-memory-leaks-in-metal-framework/69446/2 "2026-09-08T08:54:56Z")

</div>

I guess this is still true:

> [@AsyncUpdaterMessage leak issue!](https://forum.juce.com/t/asyncupdatermessage-leak-issue/7392/4):
>
> Sometimes you have to lose a battle to win the war.

> [@AsyncUpdaterMessage leak issue!](https://forum.juce.com/t/asyncupdatermessage-leak-issue/7392/5):
>
> 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.

---

<div class="post-metadata">

**Author:** ![marvinh](https://avatars.discourse-cdn.com/v4/letter/m/35a633/32.png) [@marvinh](https://forum.juce.com/u/marvinh)\
**Post date:** [September 8, 2026, 7:31pm UTC](https://forum.juce.com/t/false-positive-memory-leaks-in-metal-framework/69446/3 "2026-09-08T19:31:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [September 8, 2026, 7:45pm UTC](https://forum.juce.com/t/false-positive-memory-leaks-in-metal-framework/69446/4 "2026-09-08T19:45:25Z")

</div>

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