This sporadically happens when using the WASAPI driver. :twisted: Sometimes on close of an application, or when doing changes to the settings of the AudioDeviceManager (ie; changing the buffer size).
Sporadic enough that I’m having a hard time tracing it to debug it - and so thought I should bring it to your attention…
Strangely, I don’t receive WASAPI error outputs (when such is enabled via JUCE_WASAPI_LOGGING), so I’m really not sure why this happens. [edit: I get this one, but not when I get the leak assertion WASAPI error: 80070490]
Hmm… Thanks. Looking at the code though, I can’t see any obvious mistakes… The only thing that I spotted that might be worth adding might be an extra closeClient() call here:
(‘p’ seems to be a dangling pointer when such happens)
Edit: This seems to seldom happen in normal usage… But is frequent when impatiently mashing to make it happen purposely to understand why it happens in the first place
Normally when I see a smart pointer that seems to be dangling, it actually turns out to be the object that contains the smart-pointer which has been deleted or corrupted, but in this case that doesn’t look likely either. Very odd!
I’ve once again attempted looking into this… everything seems AOK :evil: I’ve not noticed an improper deletion order of things, or lack thereof! Even more bizarre is why nobody else has encountered this? (New Windows 8 bs?)
I'm having the same issue (albeit in an older version of Juce). Has it been fixed in newer versions? I get the same random memory leak. Occasionally, I also get a crash because p is not null; last time I caught it, the value was 0xffffffff.
Same here, good to know this isn’t a problem just for me because of some mistake in my code. This randomly happens when using WASAPI with Focusrite Scarlett 18i20. (If it matters, my current Windows WASAPI settings use 1 input channel and 4 output channels.) It seems to have a higher chance of happening if AudioDeviceSelectorComponent has been instantiated in the application.
'fraid it’s a damned old problem and there’s no way I can provide more context today (~4 years later!).
No doubt you modern JUCErs could help the core JUCE devs out by providing steps, logs, stack traces and/or self-contained code to demonstrate the problem. (Alternatively, provide a straight solution)
I have the same problem. Randomly appears on Win 7 with various JUCE versions. Currently under JUCE 4.3.1:
Here is the call stack, in case that helps
CelloPhysTest.exe!juce::LeakedObjectDetectorjuce::WasapiClasses::WASAPIDeviceBase::SessionEventCallback::LeakCounter::~LeakCounter() Line 97 C++
CelloPhysTest.exe!_execute_onexit_table::__l22::() Line 198 C++
CelloPhysTest.exe!__crt_seh_guarded_call::operator()<void (void),int (void) & __ptr64,void (void) >(__acrt_lock_and_call::__l3::void (void) && setup, _execute_onexit_table::__l22::int (void) & action, __acrt_lock_and_call::__l4::void (void) && cleanup) Line 199 C++
CelloPhysTest.exe!__acrt_lock_and_call<int (void) >(const __acrt_lock_id lock_id, _execute_onexit_table::__l22::int (void) && action) Line 882 C++
CelloPhysTest.exe!_execute_onexit_table(_onexit_table_t * table) Line 222 C++
CelloPhysTest.exe!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 211 C++
CelloPhysTest.exe!exit(int return_code) Line 283 C++
This randomly happens when using WASAPI with Focusrite Scarlett 18i20. (If it matters, my current Windows WASAPI settings use 1 input channel and 4 output channels.) It seems to have a higher chance of happening if AudioDeviceSelectorComponent has been instantiated in the application.