Re: Help debugging "Dangling reference to an invalid object." Core Data error
On 11/2/09 1:38 PM, Ben Trumbull said: >>> The only caveat is you cannot change relationships from within - >>> awakeFromFetch. This is documented: >> >> This is something I know and avoid, but it turns out this is what's >> happening afterall! Thanks! >> >> Is there some way to catch such violations? I suppose I could implement >> all relationship mutating methods, call backtrace(), and look for >> awakeFromFetch. :) > >Not really. But you can file a bug, and we can add an assertion to the >debug library easily enough. Here ya go: >Or we can enable change tracking in - >awakeFromFetch. But that would mean generic setters will dirty newly >fetched objects, and their containing documents, which people objected >to, and resulted in the current behavior. I don't mind the current behaviour. Thanks! -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: Help debugging "Dangling reference to an invalid object." Core Data error
> On 10/29/09 5:23 PM, Ben Trumbull said: > >>> Even if I do [scene addTargetsWeak:[scene targetsWeak]] I get the error. >>> >>> Does this make any sense to anyone? >> >> The only caveat is you cannot change relationships from within - >> awakeFromFetch. This is documented: > > Ben, > > This is something I know and avoid, but it turns out this is what's > happening afterall! Thanks! > > Is there some way to catch such violations? I suppose I could implement > all relationship mutating methods, call backtrace(), and look for > awakeFromFetch. :) Not really. But you can file a bug, and we can add an assertion to the debug library easily enough. Or we can enable change tracking in -awakeFromFetch. But that would mean generic setters will dirty newly fetched objects, and their containing documents, which people objected to, and resulted in the current behavior. > Basically, I have a controller class that uses KVO to observe all kinds > of things. And I'm suffering from a kind of spaghetti chain of KVO and > faulting. In my observeValueForKeyPath:ofObject:change:context: I > sometimes end up firing a fault of some object, which causes me to > reenter my observeValueForKeyPath: for some other 'context', which ends > up firing a fault of some other object, etc. At some point > awakeFromFetch is in the backtrace and at some later point I mutate a > relationship. Ick. Well, you can use prefetching to disentangle dependent controllers from firing too much stuff too lazily, or custom controller classes that override - (BOOL)fetchWithRequest:(NSFetchRequest *)fetchRequest merge:(BOOL)merge error:(NSError **)error; - Ben ___ 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
Re: Help debugging "Dangling reference to an invalid object." Core Data error
On 10/29/09 5:23 PM, Ben Trumbull said: >> Even if I do [scene addTargetsWeak:[scene targetsWeak]] I get the error. >> >> Does this make any sense to anyone? > >The only caveat is you cannot change relationships from within - >awakeFromFetch. This is documented: Ben, This is something I know and avoid, but it turns out this is what's happening afterall! Thanks! Is there some way to catch such violations? I suppose I could implement all relationship mutating methods, call backtrace(), and look for awakeFromFetch. :) Basically, I have a controller class that uses KVO to observe all kinds of things. And I'm suffering from a kind of spaghetti chain of KVO and faulting. In my observeValueForKeyPath:ofObject:change:context: I sometimes end up firing a fault of some object, which causes me to reenter my observeValueForKeyPath: for some other 'context', which ends up firing a fault of some other object, etc. At some point awakeFromFetch is in the backtrace and at some later point I mutate a relationship. Ick. This suggests to me a design flaw in my code -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: Help debugging "Dangling reference to an invalid object." Core Data error
On Oct 29, 2009, at 16:55 , Sean McBride wrote:
> On 10/22/09 4:59 PM, Melissa J. Turner said:
>
>>> I have an entity 'Scene' with a to-many relationship to an entity
>>> 'Target'. The inverse relationship is also to-many. Both relationships
>>> are optional and the delete rule for both sides is nullify.
>>>
>>> To repro, I delete all Scenes then try to save. It gives:
>>>
>>> "Dangling reference to an invalid object." = ;
>>> NSAffectedObjectsErrorKey = (
>>> (entity: Scene; id: 0x2004f32a0 >> FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343> ; ...
>>>
>>> This error gives only 4 hits with Google. :(
>>>
>>> The problem is that some Targets still have relationships to some
>>> Scenes! How can that happen? It seems like the delete rule is not
>>> doing its job.
>>
>> Does the object with the ID > BFC3-60D7AF3E579F/Scene/p343> exist in the affected store? What happens
>> when you call existingObjectWithID:error:?
>>
>> Do you know what version of the OS the bad documents were created on? A
>> lot changed in the relationship handling area in 10.6 (for the better,
>> really and truly ;-), so knowing whether your customers created them on
>> 10.5.x or 10.6.x would help narrow down the possibilities.
>
> Thanks Melissa and Ben for your replies!
>
> I have been working on this issue for days now and am getting
> increasingly confused. :)
>
> My coworker found a way to create a document (in 10.6.1) with almost the
> same problem as originally described (it complains about the inverse
> relationship instead).
>
> Examination of the XML document (as text) suggests that the object graph
> is ok.
>
> To repro: 1) open said document 2) delete a particular managed object 3)
> attempt to save -> receive "dangling reference" error. Repros 100%.
>
> I've also found that changing a particular line of my code prevents
> (100%) the error from occurring. Said line only runs when the document
> is opened (as a result of a controller getting a KVO notification).
>
> The entities in question are Scene and Target. Scene has a to-many
> 'targetsWeak' relationship. Target has a to-many 'scenesWeak'
> relationship. They are inverses. They are optional and nullify.
>
> The code snippet in question:
>
> NSSet* currentTargets = [scene targetsWeak];
> NSSet* additionallyDesiredTargets = ;
> BOOL isEqual = [currentTargets isEqualToSet:
>additionallyDesiredTargets];
> assert (isEqual);
> //if (!equal)
> {
> [scene addTargetsWeak:additionallyDesiredTargets];
> }
>
> It turns out that isEqual is always YES in this limited repro case.
> Therefore, I don't really need to change 'targetsWeak' (the 'if' body).
> But if I do anyway (the commented 'if'), I get the 'dangling reference'
> error. If I don't, I don't.
>
> Even if I do [scene addTargetsWeak:[scene targetsWeak]] I get the error.
>
> Does this make any sense to anyone?
The only caveat is you cannot change relationships from within -awakeFromFetch.
This is documented:
Otherwise, if this repros 100% of the time, file a bug and we'll take a look at
it.
- Ben
___
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
Re: Help debugging "Dangling reference to an invalid object." Core Data error
On 10/22/09 4:59 PM, Melissa J. Turner said:
>> I have an entity 'Scene' with a to-many relationship to an entity
>> 'Target'. The inverse relationship is also to-many. Both relationships
>> are optional and the delete rule for both sides is nullify.
>>
>> To repro, I delete all Scenes then try to save. It gives:
>>
>> "Dangling reference to an invalid object." = ;
>> NSAffectedObjectsErrorKey = (
>> (entity: Scene; id: 0x2004f32a0 > FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343> ; ...
>>
>> This error gives only 4 hits with Google. :(
>>
>> The problem is that some Targets still have relationships to some
>> Scenes! How can that happen? It seems like the delete rule is not
>> doing its job.
>
>Does the object with the ID BFC3-60D7AF3E579F/Scene/p343> exist in the affected store? What happens
>when you call existingObjectWithID:error:?
>
>Do you know what version of the OS the bad documents were created on? A
>lot changed in the relationship handling area in 10.6 (for the better,
>really and truly ;-), so knowing whether your customers created them on
>10.5.x or 10.6.x would help narrow down the possibilities.
Thanks Melissa and Ben for your replies!
I have been working on this issue for days now and am getting
increasingly confused. :)
My coworker found a way to create a document (in 10.6.1) with almost the
same problem as originally described (it complains about the inverse
relationship instead).
Examination of the XML document (as text) suggests that the object graph
is ok.
To repro: 1) open said document 2) delete a particular managed object 3)
attempt to save -> receive "dangling reference" error. Repros 100%.
I've also found that changing a particular line of my code prevents
(100%) the error from occurring. Said line only runs when the document
is opened (as a result of a controller getting a KVO notification).
The entities in question are Scene and Target. Scene has a to-many
'targetsWeak' relationship. Target has a to-many 'scenesWeak'
relationship. They are inverses. They are optional and nullify.
The code snippet in question:
NSSet* currentTargets = [scene targetsWeak];
NSSet* additionallyDesiredTargets = ;
BOOL isEqual = [currentTargets isEqualToSet:
additionallyDesiredTargets];
assert (isEqual);
//if (!equal)
{
[scene addTargetsWeak:additionallyDesiredTargets];
}
It turns out that isEqual is always YES in this limited repro case.
Therefore, I don't really need to change 'targetsWeak' (the 'if' body).
But if I do anyway (the commented 'if'), I get the 'dangling reference'
error. If I don't, I don't.
Even if I do [scene addTargetsWeak:[scene targetsWeak]] I get the error.
Does this make any sense to anyone?
Thanks,
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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
re: Help debugging "Dangling reference to an invalid object." Core Data error
> Core Data is giving me a validation error when I try to save a document > after making a simple change. > > I have an entity 'Scene' with a to-many relationship to an entity > 'Target'. The inverse relationship is also to-many. Both relationships > are optional and the delete rule for both sides is nullify. > > To repro, I delete all Scenes then try to save. It gives: > > "Dangling reference to an invalid object." = ; > NSAffectedObjectsErrorKey = ( > (entity: Scene; id: 0x2004f32a0 FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343> ; ... > > This error gives only 4 hits with Google. :( > > The problem is that some Targets still have relationships to some > Scenes! How can that happen? It seems like the delete rule is not > doing its job. This error happens when the MOC for a destination object is nil, the object is in a relationship but marked deleted, or the object in a relationship has a temporary objectID but is not marked inserted. Using refreshObject:mergeChanges:NO on an object with pending changes can do some of that, as can assigning a deleted object to new relationships after delete propagation has run. - Ben ___ 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
Re: Help debugging "Dangling reference to an invalid object." Core Data error
On Oct 22, 2009, at 16:26, Sean McBride wrote: > Hi all, > > Core Data is giving me a validation error when I try to save a document > after making a simple change. > > I have an entity 'Scene' with a to-many relationship to an entity > 'Target'. The inverse relationship is also to-many. Both relationships > are optional and the delete rule for both sides is nullify. > > To repro, I delete all Scenes then try to save. It gives: > > "Dangling reference to an invalid object." = ; > NSAffectedObjectsErrorKey = ( > (entity: Scene; id: 0x2004f32a0 FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343> ; ... > > This error gives only 4 hits with Google. :( > > The problem is that some Targets still have relationships to some > Scenes! How can that happen? It seems like the delete rule is not > doing its job. > > I've confirmed that each Scene receives prepareForDeletion. None of the > Scenes are finalized, they are all strongly referenced by the moc's > _deletedObjects ivar. > > Any advice on how to debug this? > > (I can repro this with 2 customer-provided documents, but I've not been > able to create a document with this problem myself. Happens on 10.5.8 > and 10.6.1; my app is garbage collected.) > Does the object with the ID exist in the affected store? What happens when you call existingObjectWithID:error:? Do you know what version of the OS the bad documents were created on? A lot changed in the relationship handling area in 10.6 (for the better, really and truly ;-), so knowing whether your customers created them on 10.5.x or 10.6.x would help narrow down the possibilities. +Melissa ___ 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
