sendChangeMessage and autorelease pool


I am having some trouble coping with NSAutoreleaseNoPool() warnings.

I am writing a fairly simple audio plugin and using an objet that is a ChangeBroadcaster. Whenever I use sendChangeMessage (from the audio processing thread context), I get a warning message stating “Objet 0x… of class NSConcreteData autoreleased with no pool in place - just leaking.”.

I am even getting these leak alerts when I do not register any listener, and under various host applications. This actually happends in juce_postMessageToSystemQueue where the stuff gets done.

Any idea on how to debug this kind of issue? Is there something I should be aware of when dealing with a ChangeBroadcaster ? Some help would be greatly appreciated!

Thanks in advance,

I have couple of questions.

  1. are you “newing” objectThatHasChanged everytime you call sendChangeMessage if you are, you should delete “objectThatHasChanged” pointer after receiving the message in the ChangeListener ? If you are not deleting the object you would be leaking memory. It would be much easier to help you if you could post your code.

  2. Are you using the latest version of juce.

  3. Can you generate this on juce demo. If you can’t, it would be a issue with your code.

Not surprising - you really shouldn’t be using a changebroadcaster (or pretty much any other complex or potentially locking function) on your audio thread.

The audio thread has to be time-critical - if something changes, your best bet is to just set a flag for another thread to respond to later. Many people won’t even use a critical section on the audio thread because on some hosts it causes problems.

I am using juce 1.50, and I am signaling that my ChangeBroadcaster itself has changed: I am simply using sendChangeMessage(this) inside of an object subclassing ChangeBroadcaster.

I thought there might be something involved related to using this mechanism from the audio thread, but then took a quick look at the Juce Demo Plugin which seems to use this kind of trick to broadcast tempo information to the UI. Am I getting confused somewhere?

Does it use a changebroadcaster? Hmm… If so, it probably shouldn’t, and I’m setting a bad example, sorry! In production code you really need to be hyper-aware of anything your audio thread does - in some multi-core hosts even the shortest critical section or memory allocation can cause spikes that wreck the audio playback.

Hi Jules,
How does it explain the leaks. I have used ChangeBroadcaster without any leaks, never tried it from thread though. Is it because sendChangeMessage is called from the thread ?

The host isn’t going to waste time creating an autorelease pool every time the audio callback happens, so any temporary obj-C objects on that thread will leak. Of course you shouldn’t be creating objects on the audio thread, so it shouldn’t matter.

It looks clear now that you’ve explained it, thanks.

Feeding a MidiKeyboardState with midi events in the processing block should thus also be avoided (as with everything that would end up creating a message), right? I am unsure of the right design to replace it though, would some state variables and juce timers do?