Fix IPlugView leaks for VST3 plugins#298
Closed
robbert-vdh wants to merge 1 commit intorncbc:masterfrom
Closed
Conversation
These `IPlugView` instances were not getting deallocated and thus cleaned up because `IPtr<T> = x;` increases `x`'s reference count if you don't explicitly make the `IPtr` owning using `Steinberg::owned` (or passing a boolean to `IPtr`'s constructor/using `OPtr`). This meant that plugins would always have at least two open `IPlugView` instances and that they would never be destroyed.
Owner
|
merged in 8b53a57 on develop branch thanks |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
I noticed that a lot of Windows VST3 plugins running through yabridge were having issues with Qtractor. When I looked into this I noticed that Qtractor creates an
IPlugViewinstance during the plugin's initialization, but it then never drops it again and instead it a secondIPlugViewinstance while the first one is still alive. I guess some plugins just don't like this.The issue was that reference counting through
IPtr<IPlugView>wasn't done correctly, so those objects would always stay at a reference count of at least 1 even when those smart pointers were dropped and the instances would thus never get destroyed. The solution is to useSteinberg::owned()whenever a call to a VST3 interface function returns a pointer. That function allows assignment to a smart pointer without increasing the reference count (which will be at 1 by default). I haven't really checked if this same issue also applied elsewhere, but from a quick skim everything else looks correct!