Plugin leaks a juce::AsyncFunction


#1

Hi,

  When closing the host, juce's LeakCounter catches a leak of a juce::AsyncFunction.

The leak occurs even when the plugin UI isn't brought up, so there isn't that much code involved.

Where should I begin to debug this?

thanks!


#2

If you try to invoke an async function but your plugin gets unloaded before the message loop has had chance to run and invoke it, then it'll certainly be leaked. That's not a huge problem because it's a tiny leak, but you should avoid doing async stuff like this until the plugin has loaded and is running.

Another approach would be to use something like an AsyncUpdater instead, which will clean up any pending updates when it gets deleted. That's safer because if you're posting an async message then are you also making sure that it can cope with being delivered after the things that it references have been deleted?


#3

Thanks Jules! I see what's going on now.

Maybe I'm doing this the wrong way. I have processBlock sending midi messages to the main thread via callAsync so I can update the data model (and UI) in response to MIDI. So if the user has a CC mapped to a knob, it will update the value for that knob. If I switch to using AsyncUpdater, will it still work when the plugin's UI isn't up?

How is such midi-mapping typically done?


#4

Nononononono.. You should watch Timur's CppCon talk about realtime code in the process callback - invoking any messaging functionality is a bad thing.


#5

Oh, silly me. I thought that CallAscync was lock-free.

It seems like I need a separate thread (HighResolutionTimer?) to handle the data model updates and a lock-free queue for communication from the audio thread to that timer thread. Does that sound right?


#6

Depends what you're doing, but probably. 

No need for a high-res timer though, a normal one is usually fine.

Or you might be able to just use an AudioProcessorValueTreeState, which handles all this stuff for you.