Re: Workaround for framework leaks?

On Aug 14, 2010, at 21:50, Gregory Weston wrote:

> Christiaan Hofman wrote:
> 
>> I have found some leaks in the system frameworks. I know exactly what property is over-retained when a new object of certain classes is created. Now my question is whether it is possible using this knowledge to avoid this leak? I could imagine to just send a release to the property. However that may be dangerous, because when Apple fixes the bug in the future that would lead to an over-release (and a crash). So would there be some way to avoid that?
> 
> Well, I would say the first thing that needs to happen is that you have to be really sure that you're seeing what you think you're seeing, and *not* misinterpreting a legitimate and intentional behavior. Overwhelmingly that seems to be the case for threads that start, "I've found some leaks in the system frameworks...." If you identified some of these leaks here, it might be that some others could verify your observations or explain them.
> 

Yes, I am 100% sure. I can consistently reproduce it using leaks and other tests (for instance sending an extra release to the object doesn't lead to a crash or a zombie). You can easily check it yourself, it's the initial PDFBorder ivar of a PDFAnnotationXXX (for any XXX that has a border initially). Here's a test: run the following with leaks:

[[[[PDFAnnotationCircle alloc] init] autorelease] setBorder:nil];

or just run the following code that should crash in memory-managed code:

[[[[[PDFAnnotationCircle alloc] init] autorelease] border] release];

You can't say that those results are as they should be.

> Next is that any bugs really need to be submitted to Apple.
> 

Of course I did, more than a year ago. I wish they also acknowledge sometimes. Or fix these bugs (there are more of those in PDFKit).

> As for dealing with them in your own code:
> 
> The best solution is to find an alternative technique that sidesteps the bug. It may not result in theoretically optimal code, but it's much better than violating the memory contract by trying to second-guess the frameworks. Try really hard to go this route. It's very rare that there's exactly one way to do something.
> 

The bug is in the designated initializer that's defined in the frameworks, that's certainly a case that cannot be sidestepped.

> Failing that, and again making absolutely sure that this is *really* a bug, I would say that you might be able to get by by coming up with a very rigorous and detectable set of circumstances under which the bug exists and deal with the issue only when those circumstances hold true.

Well, and here is the pain: where can I get such tests? Certainly retainCount is useless.

> Needless to say, one of those circumstances is going to be the precise versions of the specific framework(s) involved. If you detect any deviations from those conditions, don't mess with it.

I don't think Apple will tell me in which version of the framework they're gonna fix this?

Christiaan