Random Leak of SessionEventCallback

Hi Jules,

[attachment=0]Damned WASAPI.png[/attachment]

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:

[code] bool openClient (const double newSampleRate, const BigInteger& newChannels)


…just in case something is calling open() without first calling close().

With the additional closeClient(), I get this once in a while (only when changing buffer size, afaict);

[attachment=0]WASAPI - Buffer Changing.png[/attachment]

(‘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 :smiley:

That’s impossible… It’s a smart-pointer, so can’t ever be left dangling (!?)

My thoughts exactly! It’s really frikking weird. If I find something else out about this, I’ll post it…

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!

[attachment=0]7x Multiplier.png[/attachment]

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

It could be the WASAPI device incorrectly keeping a reference to the object.

I am getting the same leak at when closing the application.

Anybody have some ideas on how to cure this?

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 issue here ! A leak appears randomly

Same here, good to know this isn’t a problem just for me because of some mistake in my code. :slight_smile: 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 :slight_smile:

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++

Any update on this issue? Currently on JUCE 5 and believe I may be running into it.

iirc this has been solved in JUCE 6. I haven’t encountered it in… well, forever.