Le 8 mars 2014 à 03:54, Jerry Krinock je...@ieee.org a écrit :
Sixten is correct about -isDeleted. It is rarely useful.
Regarding these two kinds of managed object faults, your “second” kind is
similar to what I described in a message I posted earlier today [1]. In my
case,
On 2014 Mar 08, at 11:45, Frédéric Testuz ftes...@bluewin.ch wrote:
I suspect that in your test case, the number are tagged pointers, then they
are never deallocated as they are not allocated in first place. And are you
sure that the string tested are not static strings (NSCFConstantString)
It seems that objects can be faulted in two ways. In the first, an access will
load the data and things are fine. In the second, an access results in a crash
because the fault could not be fulfilled.
Is there a way to tell these two apart?
--
Rick
signature.asc
Description: Message
FWIW: trying to access a managed object that has been deleted, but to which
something still has a reference, can produce symptoms like the second kind
of access you describe.
Sixten
On Fri, Mar 7, 2014 at 2:21 PM, Rick Mann rm...@latencyzero.com wrote:
It seems that objects can be faulted in
On Mar 7, 2014, at 13:44 , Sixten Otto hims...@sfko.com wrote:
FWIW: trying to access a managed object that has been deleted, but to which
something still has a reference, can produce symptoms like the second kind of
access you describe.
Even the isDeleted property?
Sixten
On Fri,
Not as I recall, but it's worth noting that isDeleted only returns YES
between the time that a managed object is marked for deletion, and when
that change is committed. After that, it returns NO (which kind of sucks).
The managedObjectContext will also be nil at that point (though that CAN
happen
Sixten is correct about -isDeleted. It is rarely useful.
Regarding these two kinds of managed object faults, your “second” kind is
similar to what I described in a message I posted earlier today [1]. In my
case,
-isFault returns NO
-isDeleted returns NO
-retainCount returns +1 or greater
