Memory Leaks - Swift 5.1

[jeremycochoy]

Hello,

I open this issue because after time spent tracking memory and testing divers versions of AudioKit, it seams that the new XCode 11 Update introduced a number of memory leaks on iOS to Audiokit 4.9, 4.9.1, but also Audiokit 4.8.

I used a physical iPhone X phone for my tests.

Here is how you can reproduce what I observed:

for i in 0...3000 {
      AKMixer()
}

This simple loop should simply create and destruct object, and have no memory impact on the app. In my case, introducing this to my app increase the memory usage from 60M to 180M.
I inspected the app through the memory graph feature of XCode and here is what I see:

It seams that somehow, some pointer remain set and prevent the reference counting to return to 0.

One can argue that creating 3k AKMixer is not necessary and the impact on memory should be negligible. Which is indeed true.
Unfortunately, this is note limited to AKMixer. This also apply to AKMicrophone, AKAppleSequencers... and AKSamplers.

My use case require to destruct and rebuild frequently the audio network. Therefore rebuilding AKSamplers that play the role of instruments, through AKMidiNodes. Because if this behavior, the AKSamplers stay alive, and the memory they occupy (hundreds of Mo) stay in use. The usage of the application end up being limited to 10 interactions before it get killed (Out Of Memory).
Impact on the app:

I manually added AudioKit 4.8 to the project and removed the pod dependency. The problem is still present and this doesn't seams an issue caused by the 4.9 or 4.9.1 updates to the code base, and the problem was still present.

This problem does not exists using XCode 10 and AudioKit 4.8. I suspect this is a consequence of the update to XCode 11 and Swift 5.1. I wouldn't be surprised apple changed the behavior of some part of Core Audio, introducing this problem to audiokit.

If I can help you to sort this problem out by providing more information, or running other test, let me know. If you have any hint to where to look at to really understand whats going on and make a workaround, let me know. For now my only fix is to downgrad to the 5.0.1 toolchain and audiokit 4.8. This doesn't seams a sustainable solution 😅

[aure]

Thanks,

I wonder if this issue: #1870

and its reolution: 92021fa#r35620531

Could give us a hint as to what the new Swift/Xcode are doing.

A different way to fix the leak, shown to me later, would have to been to wrap the whole thing an autorelease pool. That wasn't necessary before, so maybe its rearing its head elsewhere.

[jeremycochoy]

Thanks for your answer. I had a look at the diff you mentioned, and it is not clear for me where the leak came from and how this change fixed it. I am note very familiar with neither swift&objc interation and objc's ARC.

For what I understand, akCustomUgenFunction take ownership of the pointer from ud (I suppose it means User Data) after casting it back to it's __bridge AKCustomUgen * type while called in the PLUMBER_INIT mode, and release the ownership (giving it back to automatic reference counting system) if called in the PLUMBER_DESTROY mode.

The line you mention was storing the Sporth stack pointer inside the custom unit generator. This affectation occurs also in the init state. I don't understand if this stack pointer is reference counted or simply a raw C pointer allocated by the sporth library ?
From the notation I would assume it's a C pointer. It is stored in the _stack member of the AKSporthStack field of the AKCustomGen, but it doesn't seams to be freed from AKSporthStack's destructor.

Is the sport_stack pointer changing between calls of akCustomUgenFunction given the same ud parameter? I would expect it is the same if I understand the behavior. But if this pointer is constant, I can't undestand why affecting it twice using setStack could create any memory leeks.

Could you quickly tell me what was the memory structure leaking and how removing this affection here prevented memory to get retained? I think that would help me to track a similar behavior in other AK components.

Thanks for your help,

[jeremycochoy]

If it can helps I think I narrowed it to

for i in 0...3000 {
      AKNode(avAudioNode: AVAudioMixerNode(), attach: true)
    }

It may be the AudioKit.engine.attach(avAudioUnit) line but I can tell for sure now.

Also, this code do not leak:

for i in 0...3000 {
      let n = AKMixer()
      n.detach()
    }

But this code still leak:

for i in 0...3000 {
      let n = AKAppleSampler()
      n.detach()
    }

and something that makes me even more worried is that this code leak:

for i in 0...3000 {
      AVAudioUnitSampler()
}

[aure]

Yeah, mixer and apple sampler are thin wrappers around apple nodes, so if they are leaking, and if avaudiounitsampler is leaking, I'm not sure what can I do, or if its even in my code where the problem arises.

[jeremycochoy]

There is at least two separate problems:

• The AVAudioUnitSampler leak
• The attach method from AVAudioEngine.

For the first case, I'd like to reach apple to report this bug so that they can investigate and hopefully fix it by January. Unfortunately I couldn't log in their reporting assistant.

For the second case, it is because the AKMixer (and others) remain attached to the audio engine.
It looks like the previous behavior of AVAudioEngine changed and now the audio engine hold a strong reference ?
A quick patch I found is to add the following lines into the AKNode implementation:

deinit {
    detach()
}

This removed memory leaks from AKMicrophone, AKMixer, etc... But I can't be sure it do not break anything somewhere else. 🙃

[aure]

I've added that code so I guess its the best we can do, can we close this issue for now?

[jeremycochoy]

I've added that code so I guess its the best we can do, can we close this issue for now?

Yes. If I find something else I will let you know. Thanks for your help.