On Jan 12, 2013, at 11:34 AM, Martin Hewitson wrote: > On 12, Jan, 2013, at 12:13 PM, Mike Abdullah <cocoa...@mikeabdullah.net> > wrote: > >> On 12 Jan 2013, at 09:01, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote: >> >>> Dear list, >>> >>> I'm still struggling to find the cause of a "CoreData could not fulfil a >>> fault" error on saving an NSPersistentDocument (see other mail thread >>> "coredata count not fulfill fault after object delete"). >>> >>> I'm wanting to check if some other object has a strong reference to the >>> deleted objects since this is a primary reason for the "could not fulfil a >>> fault" error. >>> >>> To help with this, I wondering if there is a way to get a list of all >>> objects in the run-time that have a strong reference to a particular >>> object? Is this something I can do somehow with instruments? >> >> The allocations instrument can show you all presently allocated objects. >> Find the object(s) you're interested in from that list and you can view its >> history of being retained and (auto)released, to figure out what is still >> holding onto it. > > Hmm, this proved to be ineffective. Apart from the fact that Instruments > shows me the spinning beachball of woe for many seconds when searching for an > object address, the address of the core data object that was removed only > appears once in the list, as far as I can tell.
Make sure the object allocations instrument is configured to track reference counts. Otherwise it just tracks the original allocation and any eventual deallocation. > Does it matter that I'm using ARC? Shouldn't. > I know there are a number of places where strong references are held to the > object being removed, and I'm trying to ensure I 'release' them all. Is there > a programmatic way to inspect the runtime to see what's referencing objects? The runtime doesn't know this. Even Mike's advice to use Instruments to track allocations isn't going to give you exactly what you want. It will show you which code has retained, released, and autoreleased an object, which is not quite the same thing as showing you what still holds a reference to the object. It shows you the location of where a strong reference was assigned, which is not quite the same thing as showing you which strong reference it is. But you should be able to figure things out. You have to do the work of correlating the retains and the releases to see which of the latter balance which of the former and, by process of elimination, which retains are left unbalanced. (The runtime does have special knowledge about weak references, but that doesn't help you for this purpose.) Regards, Ken _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
