Thanks Jerry & mm @mm The problem is I don't know what to put breakpoints on
@jerry My understanding is that with the core data, they have their own memory management scheme which will reuse the space of something that has been invalidated, and that invalidated is not equal to deallocated. If I examine the registers and print out the values of each, I can see the managed object at $rax - this is the exception description, and if I po [$rax userInfo], it is nil. I can see the name of the key it is trying to look up in $r14, but although this is useful information and helps me identify both the entity and the key, it really doesn't help me to narrow it down any closer than maybe 40,000 lines of code, because I believe the actual key just happens to be the one it hits first, and the real issue is why there is a key lookup happening at all. All the objects should be gone and all observers deregistered, all messages canceled etc. The code hasn't been exercised in this way before, so the issue has probably been there forever, so looking at recent changes isn't going to help. Half the code in question was written by someone who is no longer around, and although I have gone through it and found *many* issues, which I have corrected, I am still concerned that there may be something hidden in there that I am not aware of. Before posting to this list, I did manage to get through a couple of layers of invalidated object messages by finding queued notifications and dequeueing them, but seeing as the NSNotificationQueue is completely opaque as far as I can tell, I can't see whether the notification removal was effective at matching what was in the queue. From the top down approach, the places I could envisage this problem originating are: 1. NSNotificationQueue - queued notifications that get fired after I have released the MOC, and the objects have been faulted and invalidated but not removed yet. The problem here is the queue opacity. I would really like to be able to stop at my release of the MOC and look at what was queued at the time, and when I dequeue notifications, I would like to see whether the matching had actually removed the required notifications. 2. Anything that is performed using the afterDelay option. Again, the opacity of the event queue means that I don't know of a way of peeking into the event queue and seeing what is pending. 3. Anything that is using these type of facilities behind the scenes, and in this case I am thinking in particular of the drawing system where it will fire off the display message on the next run loop to coalesce the dirty rects etc. The drawing code in my application does make many calls into the underlying core data objects to tell what to draw. Wading through all of this top down is going to be very time consuming, but if necessary, then I guess that's just what I'll have to do - peel it away bit by bit. I'm not sure exactly how to get the value of "self" on a particular stack frame - I click on a frame, and use "info registers", I can try to "po" all the addresses that I see, but I don't really know what I am seeing. I sort of stumble across some registers that have some interesting data in them. I've tried to look at the GDB and Apple documentation (Debugging with GDB, Getting started with GDB), but it all seems to assume that you already know which registers are what, and how to find what you are looking for once you are at a particular frame. Are there any resources that would fill in this missing information for me so that I can debug more effectively? So say I clicked on a frame, and the assembly showed: 0x00007fff84b6c0c6 <+0723> lea -0x1427b72d(%rip),%rsi # 0x7fff708f09a0 I understand that the first couple of things are some sort of frame pointer and offset, but don't really know whether they are of any practical use to me in debugging, and the rest of it, I don't understand the assembly or the comment, but I would like to know how I can get from there to accessing the target (self) and the args to the method. Thanks Gideon On 14/06/2010, at 8:43 AM, Jerry Krinock wrote: > >> #5 0x00007fff83bf74be in -[NSManagedObject valueForKey:] () > > get the value of self, and then send some messages to it in the debugger > console. For example, if self is 0xabcdabcdabcdabcd, > > po 0xabcdabcdabcdabcd > po [0xabcdabcdabcdabcd entity] > _______________________________________________ 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
