We have a couple of JUCE apps in development, and in both apps we get a leak assert on closing the app while running in the Visual Studio debugger. It happens maybe 40% of the time. I’d assumed it was something we’re doing wrong, but I can also get it to happen in DemoRunner (v6.1.2):
Open DemoRunner in the VS debugger
Select “Browse Demos”
Select “GUI”
Select “Menus Demo”
Click to open the “Menu Position” menu, and leave it open
Click the “X” button in the window title bar to close the app
JUCE LeakedObjectDetector asserts
If this is reproducible for others, we would appreciate a fix ASAP.
Tagging @ed95 since it potentially involves the new JUCE 6.1 accessibility stuff.
Many thanks!
Ben
Edit: I tried HeavyweightLeakedObjectDetector in our apps, which gave me a stack but I didn’t find it particularly useful in this case. Feel free to DM me if you want the stacks though (I have 3 so far from our apps).
Confirmed. I’m getting the occasional leaked AccessibilityNativeHandle assert on app close on Windows 10. It seems to be related to opening secondary JUCE windows (eg. DialogWindow, ResizableWindow), and we’re also using native title bars.
Can you provide any more details that might help to track down the issue?
I’ve tried modifying the AudioPluginHost to use windows with native titlebars for plugin windows, testing the WindowsDemo in the DemoRunner, and writing a simple JUCE app which opens 50 additional windows on launch. I’m not seeing leaks in any of these tests.
If you have a consistent repro for the issue, you could try switching the normal leak detector for JUCE_HEAVYWEIGHT_LEAK_DETECTOR in the NativeAccessibilityElement class definition. When a leak is discovered, this will print a stack trace to the place where the leaked object was allocated.