# Memory Leaks with VSTs **URL:** \ **Category:** Tracktion Engine\ **Created:** [December 12, 2019, 10:34pm UTC](https://forum.juce.com/t/memory-leaks-with-vsts/36641 "2019-12-12T22:34:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![audioishi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/audioishi/32/6374_2.png) [@audioishi](https://forum.juce.com/u/audioishi)\ **Post date:** [December 12, 2019, 10:34pm UTC](https://forum.juce.com/t/memory-leaks-with-vsts/36641/1 "2019-12-12T22:34:23Z")
When I load a VST in a tracktion engine project, I always leak memory when the project closes. I typically get something like this: ``` Cleaning up temp files.. *** Leaked objects detected: 1 instance(s) of class AttributeList JUCE Assertion failure in juce_LeakedObjectDetector.h:90 *** Leaked objects detected: 1 instance(s) of class VST3HostContext JUCE Assertion failure in juce_LeakedObjectDetector.h:90 AM_MemoryRecord closing down with 338 allocations vs 331 freed AM_PreferencesAudio::destroy instance destroyed AM_PreferencesAudio::~AM_PreferencesAudio(), instanceCount after destruction: 0 4 allocations left Program ended with exit code: 0 ``` What’s the right way to cleanup/free resources in a project with external plugins? ---
**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:** [December 12, 2019, 10:58pm UTC](https://forum.juce.com/t/memory-leaks-with-vsts/36641/2 "2019-12-12T22:58:22Z")
There was a discussion about it in this thread: > [@Memory leak when hosting vst3 plugin instances](https://forum.juce.com/t/memory-leak-when-hosting-vst3-plugin-instances/35924/7): > > Yes! Yeah, some plugins may implement the ref-count differently/incorrectly and have an out-by-one-error. We’ve seen that kind of thing happen before. But I wouldn’t worry about it (other than taking this as a hint that maybe it’s time to learn about smart pointers!) I observed the same problem, it seems only to occur when scanning a new plugin (also juce plugins IIRC.). When there was no new plugin, the leaks were gone for me. So at least the harm it can do is very limited. ---
**Author:** ![audioishi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/audioishi/32/6374_2.png) [@audioishi](https://forum.juce.com/u/audioishi)\ **Post date:** [December 12, 2019, 11:31pm UTC](https://forum.juce.com/t/memory-leaks-with-vsts/36641/3 "2019-12-12T23:31:15Z")
Thanks, Daniel. When you say “new plugin” do you mean the first time a plugin is loaded in a project? Or the first time a new plugin is scanned? I’m getting leak every time a load an instance of of “U-he Zebra 2”. Weirdly, it doesn’t happen with other plugins (“NI Massive”, “NI Massive X”) I’m pretty sure it is not my code, because it only happens with some plugins, and it is only a few lines of code. ---
**Author:** ![benkuper](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/benkuper/32/899_2.png) [@benkuper](https://forum.juce.com/u/benkuper)\ **Post date:** [November 26, 2020, 10:06am UTC](https://forum.juce.com/t/memory-leaks-with-vsts/36641/4 "2020-11-26T10:06:41Z")
Hello, for those having this problem, I put a answer here : > [@Memory leak when hosting vst3 plugin instances](https://forum.juce.com/t/memory-leak-when-hosting-vst3-plugin-instances/35924/13): > > Hello, digging up this thread as I’m creating a DAW, and getting into this issue. While it’s not a “big” deal, this makes it very inconvenient when testing the software to always have memory leak notices when closing, especially when you’re looking for potential other memory leaks. Anyway, I found a workaround to force cleaning VST3HostContext pointers even if the plugin is not properly doing it. IMHO, handling it on the JUCE side is the only realistic way to deal with this issue, as the othe…