On Feb 22, 2011, at 12:21, Brad Stone wrote:

> I'm assuming since I can successfully change the string in category my 
> reference to [self note] is OK.

This is an absolutely false assumption. If, as I'm hypothesizing, [self note] 
is returning a zombie object (or it becomes a zombie object after the value is 
returned), there will be a timing window before undeath == death. During that 
window, the object may appear to function perfectly normally.

If you don't want this to take more days of debugging, you need to stop 
flailing, and *prove* that [self note] is alive. That could be difficult since 
the debugger seems to have proof that it's not. If you can prove [self note] is 
alive, then you need to look elsewhere -- the "failing" property reference may 
only be the place where the error becomes apparent, and may not itself have any 
role in the error.

So, again, how are you getting the value for [self note]? And what is its 
address? (Its 'p (void*)' value, not its 'po' value, if you want to think in 
GDB terms.) 0x00007fff5f3ffd80 doesn't look like a typical 64-bit pointer 
address. (I have a vague recollection of a past thread about GC XORing 
something into dead pointer values, producing numbers like this, but I may be 
remembering something irrelevant.) Note also that "0x00007fff843748d7 in 
_CFArrayReplaceValues ()" in the debugger output tends to suggest that [self 
note] is mucking about changing arrays.

And I agree with the earlier poster who suggested you get it to fail in code 
and then post a real backtrace.


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Reply via email to