On Mar 12, 2011, at 12:06, David Riggle wrote: > I've seen similar SecKeychain crashes whenever I put runtime code signing > checks into my code. I suspect SecKeychain is not garbage collection safe. > I've taken to doing the following to eliminate the crashes: > > [[NSGarbageCollector defaultCollector] disable]; > > err = SecCodeCopySelf(...); > err = SecCodeCopyStaticCode(...); > err = SecRequirementCreateWithString(...); > err = SecStaticCodeCheckValidity(...); > > CFRelease(...); > CFRelease(...); > CFRelease(...); > > [[NSGarbageCollector defaultCollector] enable];
Well, based on Jonathan's experience and yours, I probably said something extremely clever in my previous post, or something extremely stupid. It's looking like a SecKeychainRef is behaving like a weak reference. Now, I don't believe there's any documentation that promises that a CFType is a strong reference, *except* that about CFMakeCollectable. The result of CFMakeCollectable has to be a strong reference. If CFMakeCollectable really works like the "as if" code in the documentation says, the implication is that all CFTypes for objects in the collector zone are strong references. Or, only things *successfully* returned from CFMakeCollectable can be assumed to be strong references. Does that sound right? So, it would be interesting to see what happens if you used CFMakeCollectable instead of CFRelease in your case and in Jonathan's case. The other odd thing is that I always believed that an object with a CFRetain count (!=0) was immune from collection, even if there weren't any strong references to it. That doesn't appear to be true now. Perhaps if was true in Leopard. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
