It turns out this was a mistake of not informing the delegate on the
main thread...  Calling that on the audio thread was causing this memory
leak.  As soon as I put it on the main thread, everything is now fine,
and things are deallocating as they should be!

Patrick J. Collins
http://collinatorstudios.com


On Sat, 24 Sep 2016, Quincey Morris wrote:

> On Sep 24, 2016, at 21:07 , Patrick J. Collins 
> <[email protected]> wrote:
>
>       I tried doing:
>
>            for (int i = 0; i < frames; i++) {
>                __weak MyClass *weakMyClass = myClass;
>                [weakMyClass prepareAudio];
>                ((int16_t *)audio->mBuffers[0].mData)[i] = 
> myClass->_buffer[myClass->_index];
>            }
>
>       But that made no difference…
>
>
> As a side issue, the above really will make no difference. However, since ARC 
> is also going to retain “myClass” when you assign “channel” to it, the dance 
> with the weak variable doesn’t do anything. Also,
> using a weak variable as the receiver of the “prepareAudio” method doesn’t 
> help, because ARC retains the object around the method invocation anyway.
>
>       Can anyone tell me how in the world this weak reference is becoming 
> strong?
>
>
> There’s no such thing as a weak reference or a strong reference, there are 
> only weak and strong variables (and therefore properties). So, weak 
> references can’t “become” strong. Since your “delegate” property
> is weak, your delegate would disappear immediately on assignment to it, 
> unless it is being kept alive by some other object. AFAICT, you haven’t given 
> us any information about the actual owner of the
> delegate.
>
>       The other thing that's really weird is, since passing in nil as a 
> delegate makes the memory leak go away, I thought I could just do:
>
>        -(void)prepareAudio {
>            // stuff
>            if ([self isDone]) {
>                [self.delegate didFinish];
>                self.delegate = nil;
>            }
>            // more stuff
>        }
>
>       But that doesn't work either!  The main object still never deallocates..
>
>
> So, there is a retain cycle between the delegate and (presumably) the object 
> that’s keeping it alive. If the above is the only call to the delegate, then 
> it looks like the “didFinish” method is creating a
> retain cycle. Otherwise, some other code in the delegate (that actually 
> executes) is causing the cycle.
>
>
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to