On 12, Jan, 2013, at 10:49 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 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. Thanks, that was the checkbox I was missing. Now back to figuring out the bug. Martin > >> 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ 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