On 2010 Jun 13, at 17:34, Gideon King wrote: > 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.
That looks good to me :( > 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. Whoops/sorry. I forgot that -[NSManagedObject valueForKey:] is an Apple method so all you get is stupid registers and no symbols. (Text is not colorized in email.) So there are two ways to do this. One way would be, assuming that all of your managed objects descend from some subclass of NSManagedObject which you have defined, override -valueForKey: and NSLog in there. Mercifully, -valueForKey: is *not* listed in "Methods you Must Not Override" or "Methods you Are Discouraged From Overriding", so it might work. You may be able to reduce the fire-hose of log messages by conditioning it with if ([self isFault]). But maybe you can stand the fire-hose because it's just the last one before the exception that you're interested in. Too bad we don't have -isInvalidated. The other way is to do same logging in a Method Replacement of -valueForKey:. You see why I try and go top-down. > 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? After spending several hours reading about it one day I concluded that, because of all the indirection in Objective C, looking at registers and picking out method parameters, etc. is more much more complicated than rocket science. If anyone can explain a procedure for doing such, it would be a real "contribution to the community" :) _______________________________________________ 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
