> On Apr 3, 2016, at 07:44 , Adam R. Maxwell <amaxw...@me.com> wrote:
>
>
>> On Apr 3, 2016, at 04:55 , Christiaan Hofman <cmhof...@gmail.com
>> <mailto:cmhof...@gmail.com>> wrote:
>>
>> I think I found the problem. In several init implementations, when the
>> receiver is discarded, it calls [super dealloc] to clean up the discarded
>> self. That’s dangerous, dealloc should never be called except from a dealloc
>> override. It looks replacing these calls by [self release] (and making some
>> dealloc implementations safer to be called by uninitialized objects) and let
>> the object be cleaned up automatically gets rid of the crashes.
>
> It's been a long time since I looked at it, so I don't recall why I used
> that. Probably because of this recommendation from Apple's Obj-C runtime guy:
>
> http://lists.apple.com/archives/ObjC-Language/2008/Sep/msg00133.html
> <http://lists.apple.com/archives/ObjC-Language/2008/Sep/msg00133.html>
It turns out that the FV demo program will crash reliably with a zombie on
10.11. Commenting out the [super dealloc] calls in initializers and just
leaking doesn't fix it for me, but any reordering of code in FVWebViewIcon
seems to shift the crash. Sometimes it's a zombie FVWebViewIcon, sometimes it's
one of its ivars (NSCountedSet or NSConditionLock), depending on what I tweak.
If I bump the min number of webviews up to 50, it also doesn't crash.
I'm having to relearn Xcode, though, and I'm too pissed off at its spastic
"Behaviors" to keep going right now.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
