> On Jul 15, 2016, at 2:25, Christiaan Hofman <cmhof...@gmail.com> wrote:
>
>
>> On Jul 14, 2016, at 23:50, Maxwell, Adam R <adam.maxw...@pnnl.gov
>> <mailto:adam.maxw...@pnnl.gov>> wrote:
>>
>>
>>> On Jul 14, 2016, at 14:15, Christiaan Hofman <cmhof...@gmail.com
>>> <mailto:cmhof...@gmail.com>> wrote:
>>>
>>> It seems NSNotificationCenter isn’t the only, or perhaps the real, culprit.
>>> Even though it does seem to fix the issue on 10.11, though apparently no1t
>>> on 0.9.
>>
>> I’m not too surprised. I’ve always thought there’s a heap smasher somewhere,
>> and minor changes in code were moving things around in memory just enough to
>> avoid the crash.
>>
>>> it seems the real problem is in FVObject. That does some overrides of the
>>> ref counting. And that does not seem to work well with the weak referencing
>>> that NSNotificationCenter does.
>>
>> AFAIK NSNotificationCenter has always used unsafe, nonretained references,
>> though it looks like it does something different on iOS now (zeroing weak,
>> or whatever the jargon is). I can’t find anything in the Mac OS docs that
>> indicate it’s changed there.
>>
>>> I really don’t know what FVObject is for. Can’t we do without? Or
>>> otherwise, how should this be fixed?
>>
>> As it says in the header, FVObject just implements inline refcounting for
>> performance reasons. Many (most?) Cocoa and CF objects used to do that, and
>> it was a significant performance improvement when I implemented it. It looks
>> like Omni removed their inline refcount from OFObject in 2013, so maybe it’s
>> less of an improvement now.
>>
>> ISTR I #defined out all the code in FVObject and it still crashed, but it’s
>> been a while. Retain/release messages were balanced in the object I saw that
>> was overreleased, as far as I could tell. I also set a memory watchpoint on
>> the inline refcount address to see if it was being overwritten on the heap,
>> but only saw it change due to retain/release. Then I got sidetracked and
>> never returned to it.
>>
>> Adam
>>
>
>
> I don’t see the crasher when I comment the FVObject code out. But that’s just
> a few tries.
>
> BTW, it seems weak reference support has added some more memory management
> methods to NSObject that are not document, in particular _tryRelease and
> _isDeallocating. Not really sure how they are used though. Perhaps that’s
> related to the problem.
>
> Christiaan
>
Interesting, this does seem to be involved. I tried implementing these two
methods (well, that should be_tryRetain instead of _tryRelease), and didn’t see
the crasher anymore.
I implemented these as follows. First, change the rc by steps of 2 instead of 1
(and bit-shift back in retainCount). When deallocating (why does spell check
want defecating?), set the rc to 1 to flag it as deallocating. In _tryRetain,
return NO when this flag is set, otherwise increment (by 2) and return YES. As
for _isDeallocating, return the “1” bit flag.
So it does seem to be the case that objc messes with memory management behind
our backs, using undocumented methods. Very bad behavior. I think weak
references use _tryRetain, then thinks it retained, but in fact didn’t, because
it wasn’t using our rc ivar but rather the unused default mechanism. So the
retain count is now one lower than it should be.
BTW, do you know the __sync_fetch_and_add and related built-in functions? Are
they available on 10.6? Or perhaps they are compiler specific?
Christiaan
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
