Random Leak of SessionEventCallback

#1

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]

#2

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)
{
closeClient();

[/code]

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

#3

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:

#4

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

#5

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

#6

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!

#7

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

#8

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

#9

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

Anybody have some ideas on how to cure this?

#10

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.

#11

Same issue here ! A leak appears randomly

#12

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.

#13

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

#14

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