How reliable is Visual Studio leak detection?


#1

I’m wondering whether the VStudio leak detector is giving me false positives. Here’s the scoop:

I have a plugin that creates/juggles 100s of XmlElements. It runs fine. I do create tons of new XmlElements() but all of those are children of an xml tree under a root element declared in my top class so they all get mopped up nicely when that gets destructed - and if/when I get leaks I typically find them fairly easily. All classes have Juce leak detection - which doesn’t complain about anything. (in all fairness during development the Juce leak detector HAS complained a lot about leak mistakes :slight_smile: - and has been helpful in chasing them: in all cases it was elements I’d been sloppy about adding them to the root tree).

But for the past couple of days VS is telling me it leaks 16 bytes. Strangely, if I run the plugin as standalone in the VS debugger I get no complaints but if I run it under the Juce Audioplugin host I consistently get the warning. FWIW the processor does NOT manipulate any XmlElements - and whether I open the editor or not in the audioplugin host does not make any difference (it always leaks - seemingly the same - 16 bytes - according to Visual Studio (but nothing according to Juce).

I spent an afternoon undressing the application (commenting out code that creates XmlElements) trying to find what might get leaked when but can’t find anything (so far). The XmlElements get created based on user interaction with the plugin - whether I make it create TONs of elements or not does not seem to make a difference either.

I installed a trial version of Deleaker - which offers no complaints either.

So … does the VS built-in leak detector tend to give false positives? Any experience others have would be appreciated!


#2

This seems to be an unavoidable leak, see Jules’ answer here:


#3

In other words, it’s not about the XmlElements, those leaking would be detected by the JUCE leak detection stuff.


#4

Yeah - but I’m not dynamically creating anything but XmlElements! Ain’t that weird?


#5

As mentioned in the thread linked above, the leaked bytes come from the Messaging system. Therefore, it doesn’t matter what you dynamically create in your code, as the builtin JUCE code produces this (apparently unfixable) issue.