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
