Before 5.0.2, whenever my plugin exited it did so cleanly. Visual Studio 2017 would then output three minor leaks into the output window (only 16-24 bytes, and only three of them). I figured it must be some legacy code of mine that I’ll clean up later.
Since the update to 5.0.2 suddenly an assertion fails that tells me that one StringArray was leaked. But I don’t use the StringArray class. This tells me that someone added the leak-detector to a juce class somewhere and it’s triggering now. But I have no idea where to look etc.
Does somebody from the JUCE developers remember adding a leak-detector recently, to a class that didn’t have one before?
Have you tried continuing execution past the StringArray leak assertion in VS2017? Often you can get a sense of where it is from further cascading leaks. Good luck tracking it down, and maybe you can fix your three existing leaks while you’re there.
Yes, and there are no further leaks. Again: I’m not expecting help in tracking down a leak I created, but rather find out where the leak in the JUCE code is that I might have triggered.
In my whole code there is not a single StringArray.
might be the other way round: if you leak an object, that does NOT have a leak detector, but contains the StringArray with the leak detector, then you only see the StringArray. But clicking continue cannot find an owning instance, that has no leak detector…
grep for StringArray and you’ll see a lot of JUCE classes use them – then check the JUCE commit history for any changes involving those classes which you’re using.
I still get the leak, but not the assertion. That’s why I think the JUCE team added a leak-detector to a class that previously didn’t have one. With JUCE 5.0.1 I only get the leaked StringArray in the debug output of the compiler after I quit.
Already did a search in the diff, but nothing conclusive. I don’t want to spend any more time on this. My aim was to notify the developers and let them know about this, not debugging their code. They broke it, it’s literally their job to fix this.
I’ll install the Intel Inspector in the next few days and then can give more concrete help. @jules, @t0m etc. should be able to figure it out way easier than I can with my tools available.
To see only a single StringArray object leaking means that it’d need to be inside a class that is not itself leak-detected, with no other leak-detected member variables. And it would have to be empty too, otherwise you’d see leaked strings too.
So I just did a very laborious search of every StringArray in our codebase and apart from a couple of OSC classes there are none that fit that description.
So… I can only assume that you’re misunderstanding or misreporting something, or just have some kind of random memory corruption that’s triggering random behaviour. Are you SURE you carried on running to see other leaks?
Our job is indeed to fix things. But I wish it also paid a bonus for every forum post that accused us of breaking something, and then turned out to be a silly mistake that the user had made themselves!
I use the VST2 version with my own mini-vst-host. The only way that could cause the problem is if my mini-vst-host would write into the plugins memory. It’s not impossible (code is 12+ years old at this point).
I’ll find out once I get around installing the Intel Compiler and it’s Inspector.
Should that turn out to be true (that it’s my vst2-hosting-code, not a JUCE problem) then I’ll gladly PayPal you some beer money. Just PM me your PayPal address.
OK. I’ve used savihost as my debugging host now and the problem is gone.
I owe the JUCE team an apology. Sorry for wasting your time on a wild goose chase. It seems I have a bug in my own mini-vst-host that causes the loaded plugin to misbehave.
@jules don’t forget to PM me your PayPal address. There is a bonus waiting for you.
