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
