DemoRunner: Leaked AccessibilityNativeHandle object

General JUCE discussion
#1

Hi all,

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):

  1. Open DemoRunner in the VS debugger
  2. Select “Browse Demos”
  3. Select “GUI”
  4. Select “Menus Demo”
  5. Click to open the “Menu Position” menu, and leave it open
  6. Click the “X” button in the window title bar to close the app
  7. 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).

#2

I somehow neglected to mention that the leaked object is a juce::AccessibilityNativeHandle, and that it happens on Windows :roll_eyes:

*** Leaked objects detected: 1 instance(s) of class AccessibilityNativeHandle
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
#3

Thanks for reporting. This should be fixed on develop now:

1 Like
*** Leaked objects detected: 2 instance(s) of class AccessibilityHandler
#4

Thank you, @ed95!

#5

Still getting the same leakage with ResizableWindow in my standalone app (JUCE 6.1.3, includes mentioned fix)

juce::ResizableWindow w (V4CS, true);
w.setUsingNativeTitleBar (true);

*** Leaked objects detected: 1 instance(s) of class AccessibilityNativeHandle
JUCE Assertion failure in juce_LeakedObjectDetector.h:92

Looks it’s related to setUsingNativeTitleBar method. If i set it to false, leakage dissapears.

@ed95 can you please check this?

Thx!!!

#6

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.

#7

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.