Re: Workaround for framework leaks?

"Gary L. Wade" <garywade-9iVW/[email protected]> Sun, 15 Aug 2010 17:10:49 -0700
Newsgroups gmane.comp.macosx.devel
Message-ID <C88DD019.2CFB1%[email protected]>
NSSpeechSynthesizer -objectForProperty:error: is the offender; it always
returns a copy of whatever is being requested rather than either an internal
version or even an autoreleased copy.  Very nasty!

I'm not sure about Apple's current policy, but I've used incident reports in
the past where there was an actual bug in their code, and those were
refunded, so it may cost you nothing if it's really their bug.

I saw a case the other day of another issue somewhere (forgot where and I
don't have the source code in front of me, but it wasn't speech synthesizer)
where an alloc-init form would cause a double release if I did a release
after I was done with the object rather than using the autorelease-creation
form (the object was being handed off to another method that apparently
decided to release it without any documentation that it was going to), so
trying that route where possible may be a solution without Apple's input.

If you know there's a leak bug in Apple's code that you can't work around in
a safe manner, you might include in some FAQ of your product about what your
customers should do to clear things up (quit, restart, etc.).  If you can
track what the most parent-based object is that is leaking (it appears leaks
returns all objects leaked, even those referenced by a leak, which seems
both right and wrong) and can identify when you're at a clean enough state,
you could try releasing it at that time, making sure the user knows you're
doing something scary.  Of course, this all depends on your application,
users, and lots of other things that you'll have to judge for yourself.

On 08/15/2010 4:27 PM, "Christiaan Hofman" <[email protected]> wrote:

> 
> On Aug 16, 2010, at 1:00, Gary L. Wade wrote:
> 
>> There are indeed leaks in the frameworks. I verified at WWDC with one
>> engineer (code was looked at) they had chosen to retain a delegate in one
>> framework even though delegates generally do not get retained unless
>> documented.
> 
> Can you tell where, in case I ever need it? The only cases I do know about
> this is in CoreAnimation, but that's partly documented (but not completely,
> because of undocumented stuff that happens behind the scenes, and which adds
> more retains that are not documented).
> 
>> Also one of the methods in the speech synthesizer returns a dictionary of
>> properties (phonemes) you must release even though it's name suggests you
>> must retain it yourself if you want it. Unfortunately, I can never have a
>> clean analyzer build due to this. If you believe in your case, write a bug
>> and possibly use an incident report for a definite solution.
>> 
>> - Gary L. Wade (Sent from my iPhone)
> 
> This particular framework (PDFKit) is actually full of bugs, some were
> confirmed by Apple engineers. Some are considerably more serious (reproducible
> crashers), and there I do not agree with the statement that you should only
> add a fix when you're sure that the bug is there. But in this case, I think it
> may just be better to do nothing (fixing a leak while risking a crasher is not
> a good idea, while fixing a crasher while risking a leak my be worthwhile).
> 
> Christiaan
>