Re: Accessing a managedObject property from within an accessor of another property

2011-02-23 Thread Brad Stone
[A]nd then it occurred to me that a computer is a stupid machine with the 
ability to do incredibly smart things, while computer programmers are smart 
people with the ability to do incredibly stupid things.  They are, in short, a 
perfect match.  ~Bill Bryson

On Feb 22, 2011, at 11:42 PM, Quincey Morris wrote:

 That's a lot of information you posted. :)
 
 Unfortunately, *based on the posted information* there's nothing obviously 
 wrong except that you've shot yourself in the foot using the debugger. Let's 
 look, for example,  at what one of the backtraces is telling you. You 
 triggered this by typing 'po self' in the debugger:
 
 On Feb 22, 2011, at 19:34, Brad Stone wrote:
 
 Breakpoint 28, -[SRMainWindowController toggleLock:] (self=0x2000df5e0, 
 _cmd=0x1000a9239, sender=0x2000df5e0) at SRMainWindowController.m:2897
 2897 [note setIsEncrypted:[NSNumber numberWithBool:YES]];
 The program being debugged stopped while in a function called from GDB.
 When the function (_NSPrintForDebugger) is done executing, GDB will silently
 stop (instead of continuing to evaluate the expression containing
 the function call).
 
 A function called from the debugger as a result of 'po self' failed. What 
 function? It's not clear yet, but it *is* clear what failed -- that function 
 directly or indirectly called 'toggleLock:' *again* -- the method you were in 
 when you started all this debugging activity. Why did it stop? It hit the 
 breakpoint that you put in that code.
 
 This backtrace is enlightening, unlike the earlier ones, because it shows 
 what the debugger was trying to do:
 
 Here's a backtrace right after po #3 before I'm out of setIsEncrypted
 backtrace
 #0  -[SRMainWindowController toggleLock:] (self=0x2000df5e0, 
 _cmd=0x1000a9239, sender=0x2000df5e0) at SRMainWindowController.m:2897
 #1  0x00010002dae9 in -[SRMainWindowController getEncryptionKey] 
 (self=0x2000df5e0, _cmd=0x1000a7210) at SRMainWindowController.m:2948
 #2  0x000198d2 in -[Note category] (self=0x20027bda0, 
 _cmd=0x7fff85450184) at Note.m:257
 #3  0x000189c8 in -[Note description] (self=0x20027bda0, 
 _cmd=0x7fff83c821e8) at Note.m:56
 
 The debugger was trying to execute [note description], which is what it does 
 to get a description to display as a result of 'po note'. Normally, the 
 standard 'description' in NSObject is called, which just prints the address 
 of the object and its class. You, apparently have overridden 'description' in 
 the Note class, and it apparently invokes 'category', which invokes 
 '-[SRMainWindowController getEncryptionKey]', which invokes 'toggleLock:', 
 which is why it hits the breakpoint again.
 
 Note that (apparently) if isEncrypted is NO, then 'getEncryptionKey' isn't 
 invoked, and so 'toggleLock' isn't invoked either. That's why setting 
 isFlagged instead didn't crap out in the debugger.
 
 Other than indicating an inappropriate design of your 'description' override, 
 there's absolutely no indication of anything wrong here at all. It looks like 
 you've been chasing a chimera. :)
 
 Obviously I may be overlooking something, but step 1 is to fix your 
 'description' method so that it doesn't cause Core Data fetches. 
 
 #4  0x7fff868a386b in _NSPrintForDebugger ()
 #5  function called from gdb
 #6  -[Note setIsEncrypted:] (self=0x20027bda0, _cmd=0x1000a6eb8, 
 value=0x7fff70886280) at Note.m:206
 #7  0x00010002d5c9 in -[SRMainWindowController toggleLock:] 
 (self=0x2000df5e0, _cmd=0x1000a9239, sender=0x2000867e0) at 
 SRMainWindowController.m:2897
 #8  0x7fff83b2afbf in -[NSToolbarButton sendAction:to:] ()
 #9  0x7fff8379c135 in -[NSToolbarItemViewer mouseDown:] ()
 #10 0x7fff8368934f in -[NSWindow sendEvent:] ()
 #11 0x7fff835bea86 in -[NSApplication sendEvent:] ()
 #12 0x7fff835554da in -[NSApplication run] ()
 #13 0x7fff8354e1a8 in NSApplicationMain ()
 #14 0x00016b60 in main (argc=1, argv=0x7fff5fbff628) at main.m:13
 

___

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


Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Brad Stone
I've been trying for days to determine why I get EXC_BAD_ACCESS when I try to 
access a managedObject property from within an accessor of another property?

this code in main.m
[[self note] setValue:@HELLO WORLD forKey:@category];
NSNumber *tmpVal = [NSNumber numberWithBool:![[[self note] 
valueForKey:@isEncrypted] boolValue]]; // if I type po [self note] I see the 
note description
[[self note] setValue:tmpVal forKey:@isEncrypted]; // if I type po [self 
note] after this I get EXEC_BAD_ACCESS

The if statement in the accessor is causing the problem:
- (NSString *)category {
NSString * tmpValue;

[self willAccessValueForKey:@category];
tmpValue = [self primitiveCategory];
[self didAccessValueForKey:@category];

if ([[self valueForKey:@isEncrypted] boolValue]) {  // THIS IS CAUSING 
THE PROBLEM
// code to decrypt tmpValue
}

return tmpValue;
}

When I replace: if ([[self valueForKey:@isEncrypted] boolValue]) with if (1 
== 2 ) or if (1 == 1 ) it works

FYI: in my .h file @property (nonatomic, retain) NSNumber * isEncrypted; and 
@dynamic isEncrypted; in .m___

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


Fwd: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Brad Stone
FYI - my managedObject is defined as such:

@interface Note :  NSManagedObject  
{
}

@property (nonatomic, retain) NSNumber * uid;
@property (nonatomic, retain) NSString * category;
@property (nonatomic, retain) NSNumber * isEncrypted;

@interface Note (CoreDataGeneratedPrimitiveAccessors)

- (NSString *)primitiveCategory;
- (void)setPrimitiveCategory:(NSString *)value;

@end


@implementation Note 

@dynamic uid;
@dynamic category;
@dynamic isEncrypted;

- (NSString *)category 
{


NSString * tmpValue;

[self willAccessValueForKey:@category];
tmpValue = [self primitiveCategory];   
[self didAccessValueForKey:@category];

   if ([[self valueForKey:@isEncrypted] boolValue]) {
//code to decrypt tmpValue
}
 
return tmpValue;
}

- (void)setCategory:(NSString *)value 
{   


if ([[self valueForKey:@isEncrypted] boolValue]) {
// code to encrypt tmpValue
}
 

[self willChangeValueForKey:@category];
[self setPrimitiveCategory:value];
[self didChangeValueForKey:@category];
}

- (BOOL)validateCategory:(id *)valueRef error:(NSError **)outError 
{
// Insert custom validation logic here.
return YES;
}
___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Uli Kusterer
On 22.02.2011, at 16:13, Brad Stone wrote:
 FYI - my managedObject is defined as such:
 
 @interface Note :  NSManagedObject  
 {
 }

That's probably not your problem, but just to eliminate it as a cause: You 
should prefix your class names. Apple has been known to create internal private 
classes with un-prefixed names (like Account). And once one class with a 
particular name has been loaded, requests to load any other class of the same 
name will be ignored. Anyone trying to create an instance of such a class will 
get the first class that was loaded, which is probably something completely 
different.

So I recommend choosing your own three-character prefix (BST?), just in case 
there's some private Apple class named Note.

Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
http://www.zathras.de



___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Brad Stone
Yes, all my other classes are prefixed with SR since this one.  I haven't 
gotten back to fixing this.

On Feb 22, 2011, at 10:22 AM, Uli Kusterer wrote:

 On 22.02.2011, at 16:13, Brad Stone wrote:
 FYI - my managedObject is defined as such:
 
 @interface Note :  NSManagedObject  
 {
 }
 
 That's probably not your problem, but just to eliminate it as a cause: You 
 should prefix your class names. Apple has been known to create internal 
 private classes with un-prefixed names (like Account). And once one class 
 with a particular name has been loaded, requests to load any other class of 
 the same name will be ignored. Anyone trying to create an instance of such a 
 class will get the first class that was loaded, which is probably something 
 completely different.
 
 So I recommend choosing your own three-character prefix (BST?), just in case 
 there's some private Apple class named Note.
 
 Cheers,
 -- Uli Kusterer
 The Witnesses of TeachText are everywhere...
 http://www.zathras.de
 
 
 

___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Quincey Morris
On Feb 22, 2011, at 06:19, Brad Stone wrote:

 I've been trying for days to determine why I get EXC_BAD_ACCESS when I try to 
 access a managedObject property from within an accessor of another property?
 
 this code in main.m
 [[self note] setValue:@HELLO WORLD forKey:@category];
 NSNumber *tmpVal = [NSNumber numberWithBool:![[[self note] 
 valueForKey:@isEncrypted] boolValue]]; // if I type po [self note] I see 
 the note description
 [[self note] setValue:tmpVal forKey:@isEncrypted]; // if I type po [self 
 note] after this I get EXEC_BAD_ACCESS
 
 The if statement in the accessor is causing the problem:
 - (NSString *)category {
 NSString * tmpValue;
 
[self willAccessValueForKey:@category];
tmpValue = [self primitiveCategory];
[self didAccessValueForKey:@category];
   
if ([[self valueForKey:@isEncrypted] boolValue]) {  // THIS IS CAUSING 
 THE PROBLEM
// code to decrypt tmpValue
}
   
return tmpValue;
 }

No answer, but a couple of points:

-- What happens if you write 'note.isEncrypted' (or '[note isEncrypted]') 
instead of '[note valueForKey: @isEncrypted]'?

-- What happens if you code your own custom accessors for isEncrypted, like 
you've done for category?

-- EXC_BAD_ACCESS is often a symptom of a memory management problem. Is there a 
problem with the object being returned by '[self note]'? You didn't show code 
for where this is implemented. It's possible that you failed to retain the 
object, or, if you're using garbage collection, returned an object with no 
strong references, or perhaps you returned a zombie object.

What happens in the above code if you set first a local variable to '[[self 
note] retain]' and use the local variable in place of the other references to 
'[self note]'?


___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Brad Stone
Quincey,

Thanks for relying.  It's good to have another developer to talk this thru with.

1) customer accessors for isEncrypted didn't work (I have a set exactly like 
category)
2) I'm using garbage collection
3) I tried [note isEncrypted] same error
4) i tried using a local ivar i..e Note *thisNote = [self note], no change

I've been trying these variations for days.


On Feb 22, 2011, at 12:44 PM, Quincey Morris wrote:

 On Feb 22, 2011, at 06:19, Brad Stone wrote:
 
 I've been trying for days to determine why I get EXC_BAD_ACCESS when I try 
 to access a managedObject property from within an accessor of another 
 property?
 
 this code in main.m
 [[self note] setValue:@HELLO WORLD forKey:@category];
 NSNumber *tmpVal = [NSNumber numberWithBool:![[[self note] 
 valueForKey:@isEncrypted] boolValue]]; // if I type po [self note] I see 
 the note description
 [[self note] setValue:tmpVal forKey:@isEncrypted]; // if I type po [self 
 note] after this I get EXEC_BAD_ACCESS
 
 The if statement in the accessor is causing the problem:
 - (NSString *)category {
 NSString * tmpValue;
 
   [self willAccessValueForKey:@category];
   tmpValue = [self primitiveCategory];
   [self didAccessValueForKey:@category];
  
   if ([[self valueForKey:@isEncrypted] boolValue]) {  // THIS IS CAUSING 
 THE PROBLEM
   // code to decrypt tmpValue
   }
  
   return tmpValue;
 }
 
 No answer, but a couple of points:
 
 -- What happens if you write 'note.isEncrypted' (or '[note isEncrypted]') 
 instead of '[note valueForKey: @isEncrypted]'?
 
 -- What happens if you code your own custom accessors for isEncrypted, like 
 you've done for category?
 
 -- EXC_BAD_ACCESS is often a symptom of a memory management problem. Is there 
 a problem with the object being returned by '[self note]'? You didn't show 
 code for where this is implemented. It's possible that you failed to retain 
 the object, or, if you're using garbage collection, returned an object with 
 no strong references, or perhaps you returned a zombie object.
 
 What happens in the above code if you set first a local variable to '[[self 
 note] retain]' and use the local variable in place of the other references to 
 '[self note]'?
 
 

___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Quincey Morris
On Feb 22, 2011, at 10:10, Brad Stone wrote:

 2) I'm using garbage collection

Then my money's on a memory management error with the [self note] object. Can 
you show the code for [self note] and/or show the strong reference that keeps 
it alive?


___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Quincey Morris
On Feb 22, 2011, at 10:10, Brad Stone wrote:

 2) I'm using garbage collection

Also, it's worth checking that you really have garbage collection turned on. 
It's easy mistake to turn it on in the project build settings and not realize 
that the target settings turn it off. The symptoms you've been describing are 
exactly consistent with this.


___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Felix Franz

On Feb 22, 2011, at 3:19 PM, Brad Stone wrote:

 I've been trying for days to determine why I get EXC_BAD_ACCESS when I try to 
 access a managedObject property from within an accessor of another property?

Could you post the stack trace? Just for debugging purposed: What happens if 
you define another method (not an CoreData-Property)
like:

- (NSString*) categoryPlain
{
 NSString* categoryEncryptedOrNot = self.category;
 if ([self.isEncrypted boolValue]) {
  // decrypt
  return decryptedCategory;
 } 
 return categoryEncryptedOrNot;
}   

and leave category as a @dynamic-property. Maybe CoreDate gets confused if 
you retrieve the value, but change 
it after your didAccessValueForKey:-message send

Cheers, 

Felix

 
 this code in main.m
 [[self note] setValue:@HELLO WORLD forKey:@category];
 NSNumber *tmpVal = [NSNumber numberWithBool:![[[self note] 
 valueForKey:@isEncrypted] boolValue]]; // if I type po [self note] I see 
 the note description
 [[self note] setValue:tmpVal forKey:@isEncrypted]; // if I type po [self 
 note] after this I get EXEC_BAD_ACCESS
 
 The if statement in the accessor is causing the problem:
 - (NSString *)category {
 NSString * tmpValue;
 
[self willAccessValueForKey:@category];
tmpValue = [self primitiveCategory];
[self didAccessValueForKey:@category];
   
if ([[self valueForKey:@isEncrypted] boolValue]) {  // THIS IS CAUSING 
 THE PROBLEM
// code to decrypt tmpValue
}
   
return tmpValue;
 }
 
 When I replace: if ([[self valueForKey:@isEncrypted] boolValue]) with if (1 
 == 2 ) or if (1 == 1 ) it works
 
 FYI: in my .h file @property (nonatomic, retain) NSNumber * isEncrypted; and 
 @dynamic isEncrypted; in .m___
 
 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/franz%40ergosign.de
 
 This email sent to fr...@ergosign.de

-- 
Mit freundlichen Grüßen,

Felix Franz

Lead Software Engineer

ERGOSIGN GmbH
Europa-Allee 12
66113 Saarbrücken
Phone: +49 681 98 84 12 14
Fax: +49 681 98 84 12 10
www.ergosign.de

HRB 11850
Amtsgericht Saarbrücken

Geschäftsführung:
Dr. Marcus Plach
Prof. Dr. Dieter Wallach

Sitz der Gesellschaft:
Saarbrücken







___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Quincey Morris
On Feb 22, 2011, at 12:21, Brad Stone wrote:

 I'm assuming since I can successfully change the string in category my 
 reference to [self note] is OK.

This is an absolutely false assumption. If, as I'm hypothesizing, [self note] 
is returning a zombie object (or it becomes a zombie object after the value is 
returned), there will be a timing window before undeath == death. During that 
window, the object may appear to function perfectly normally.

If you don't want this to take more days of debugging, you need to stop 
flailing, and *prove* that [self note] is alive. That could be difficult since 
the debugger seems to have proof that it's not. If you can prove [self note] is 
alive, then you need to look elsewhere -- the failing property reference may 
only be the place where the error becomes apparent, and may not itself have any 
role in the error.

So, again, how are you getting the value for [self note]? And what is its 
address? (Its 'p (void*)' value, not its 'po' value, if you want to think in 
GDB terms.) 0x7fff5f3ffd80 doesn't look like a typical 64-bit pointer 
address. (I have a vague recollection of a past thread about GC XORing 
something into dead pointer values, producing numbers like this, but I may be 
remembering something irrelevant.) Note also that 0x7fff843748d7 in 
_CFArrayReplaceValues () in the debugger output tends to suggest that [self 
note] is mucking about changing arrays.

And I agree with the earlier poster who suggested you get it to fail in code 
and then post a real backtrace.


___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Brad Stone
In my Note entity:
self = (Note *)0x20027bda0

In my .h file have this property defined: @property (nonatomic, retain) 
NSNumber * isFlagged; and this in .m @dynamic isFlagged; and no custom accessors

New code in my Note entity:
- (void)setIsEncrypted:(NSNumber *)value {
// see po #1 which I typed here

[self willChangeValueForKey:@isFlagged];  
[self setPrimitiveValue:value forKey:@isFlagged];
[self didChangeValueForKey:@isFlagged];

// see po #2 which I typed here

[self willChangeValueForKey:@isEncrypted];
[self setPrimitiveValue:value forKey:@isEncrypted];
[self didChangeValueForKey:@isEncrypted];

// see po #3 which I typed here

}

po #1
po self
Note uid:319649395851582
 category:None
 isFlagged:0
 isEncrypted:0

po #2
po self
Note uid:319649395851582
 category:None
 isFlagged:1
 isEncrypted:0

po #3
po self

Breakpoint 28, -[SRMainWindowController toggleLock:] (self=0x2000df5e0, 
_cmd=0x1000a9239, sender=0x2000df5e0) at SRMainWindowController.m:2897
2897[note setIsEncrypted:[NSNumber numberWithBool:YES]];
The program being debugged stopped while in a function called from GDB.
When the function (_NSPrintForDebugger) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).

Here's a backtrace right after po #3 before I'm out of setIsEncrypted
backtrace
#0  -[SRMainWindowController toggleLock:] (self=0x2000df5e0, _cmd=0x1000a9239, 
sender=0x2000df5e0) at SRMainWindowController.m:2897
#1  0x00010002dae9 in -[SRMainWindowController getEncryptionKey] 
(self=0x2000df5e0, _cmd=0x1000a7210) at SRMainWindowController.m:2948
#2  0x000198d2 in -[Note category] (self=0x20027bda0, 
_cmd=0x7fff85450184) at Note.m:257
#3  0x000189c8 in -[Note description] (self=0x20027bda0, 
_cmd=0x7fff83c821e8) at Note.m:56
#4  0x7fff868a386b in _NSPrintForDebugger ()
#5  function called from gdb
#6  -[Note setIsEncrypted:] (self=0x20027bda0, _cmd=0x1000a6eb8, 
value=0x7fff70886280) at Note.m:206
#7  0x00010002d5c9 in -[SRMainWindowController toggleLock:] 
(self=0x2000df5e0, _cmd=0x1000a9239, sender=0x2000867e0) at 
SRMainWindowController.m:2897
#8  0x7fff83b2afbf in -[NSToolbarButton sendAction:to:] ()
#9  0x7fff8379c135 in -[NSToolbarItemViewer mouseDown:] ()
#10 0x7fff8368934f in -[NSWindow sendEvent:] ()
#11 0x7fff835bea86 in -[NSApplication sendEvent:] ()
#12 0x7fff835554da in -[NSApplication run] ()
#13 0x7fff8354e1a8 in NSApplicationMain ()
#14 0x00016b60 in main (argc=1, argv=0x7fff5fbff628) at 
main.m:13___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Brad Stone
SCENARIO 1:

The thread is:
0 - [SRMainWindowController toggleLock:]  //self = (SRMainWindowController *) 
0x20009d440
1-[NSToolbarButton sendAction:to:]

- (IBAction)toggleLock:(id)sender {

NSError *fetchError = nil;
NSArray *fetchResults;
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];

NSEntityDescription *entity = [NSEntityDescription 
entityForName:@Note inManagedObjectContext:[self managedObjectContext]];
[fetchRequest setEntity:entity];
fetchResults = [[self managedObjectContext] 
executeFetchRequest:fetchRequest error:fetchError];

Note *note = nil;
if (fetchRequest != nil  [fetchResults count] == 1)  {
note = [fetchResults objectAtIndex:index];  //note = (Note 
*)0x20027bfe0
}


if (note) {
[note setIsEncrypted:[NSNumber numberWithBool:YES]];  // see below
}
}




When I jump into  note setIsEncrypted:[NSNumber numberWithBool:YES]]; in the 
Note managedObject

self = (Note *)0x20027bfe0  // same as above
value = (NSCFBoolean *) 0x7fff70886280

po self
Note uid:319649395851582
 category:None
 isEncrypted:0
 isFlagged:0
(gdb) 

- (void)setIsEncrypted:(NSNumber *)value {
[self willChangeValueForKey:@isEncrypted];
[self setPrimitiveValue:value forKey:@isEncrypted];
[self didChangeValueForKey:@isEncrypted];
// see backtrace
}

As soon as I po after the setPrimitive I get:

Breakpoint 26, -[SRMainWindowController toggleLock:] (self=0x20009d440, 
_cmd=0x1000a92b1, sender=0x20009d440) at SRMainWindowController.m:2891
2891if (fetchRequest != nil  [fetchResults count] == 1)  {
The program being debugged stopped while in a function called from GDB.
When the function (_NSPrintForDebugger) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).




#0  -[Note setIsEncrypted:] (self=0x2000b7600, _cmd=0x1000a6eb8, 
value=0x7fff70886280) at Note.m:206
#1  0x00010002d5c9 in -[SRMainWindowController toggleLock:] 
(self=0x200078f80, _cmd=0x1000a9239, sender=0x2000a0c20) at 
SRMainWindowController.m:2897
#2  0x7fff83b2afbf in -[NSToolbarButton sendAction:to:] ()
#3  0x7fff8379c135 in -[NSToolbarItemViewer mouseDown:] ()
#4  0x7fff8368934f in -[NSWindow sendEvent:] ()
#5  0x7fff835bea86 in -[NSApplication sendEvent:] ()
#6  0x7fff835554da in -[NSApplication run] ()
#7  0x7fff8354e1a8 in NSApplicationMain ()
#8  0x00016b60 in main (argc=1, argv=0x7fff5fbff628) at main.m:13




SCENARIO 2:
I created a second scenario as a test to try to shed more light.  Scenario 1 
and scenario 2 are **exactly** the same but I'm setting another NSNumber, 
isFlagged to YES in the setIsEncrypted accessor and it gets set correctly 
without an exception but isEncrypted still causes one.


In SRMainWindowController:
self = (SRMainWindowController *)0x2000df5e0
note = (Note *)0x20027bda0

 see earlier email for second 
part___

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: Accessing a managedObject property from within an accessor of another property

2011-02-22 Thread Quincey Morris
That's a lot of information you posted. :)

Unfortunately, *based on the posted information* there's nothing obviously 
wrong except that you've shot yourself in the foot using the debugger. Let's 
look, for example,  at what one of the backtraces is telling you. You triggered 
this by typing 'po self' in the debugger:

On Feb 22, 2011, at 19:34, Brad Stone wrote:

 Breakpoint 28, -[SRMainWindowController toggleLock:] (self=0x2000df5e0, 
 _cmd=0x1000a9239, sender=0x2000df5e0) at SRMainWindowController.m:2897
 2897  [note setIsEncrypted:[NSNumber numberWithBool:YES]];
 The program being debugged stopped while in a function called from GDB.
 When the function (_NSPrintForDebugger) is done executing, GDB will silently
 stop (instead of continuing to evaluate the expression containing
 the function call).

A function called from the debugger as a result of 'po self' failed. What 
function? It's not clear yet, but it *is* clear what failed -- that function 
directly or indirectly called 'toggleLock:' *again* -- the method you were in 
when you started all this debugging activity. Why did it stop? It hit the 
breakpoint that you put in that code.

This backtrace is enlightening, unlike the earlier ones, because it shows what 
the debugger was trying to do:

 Here's a backtrace right after po #3 before I'm out of setIsEncrypted
 backtrace
 #0  -[SRMainWindowController toggleLock:] (self=0x2000df5e0, 
 _cmd=0x1000a9239, sender=0x2000df5e0) at SRMainWindowController.m:2897
 #1  0x00010002dae9 in -[SRMainWindowController getEncryptionKey] 
 (self=0x2000df5e0, _cmd=0x1000a7210) at SRMainWindowController.m:2948
 #2  0x000198d2 in -[Note category] (self=0x20027bda0, 
 _cmd=0x7fff85450184) at Note.m:257
 #3  0x000189c8 in -[Note description] (self=0x20027bda0, 
 _cmd=0x7fff83c821e8) at Note.m:56

The debugger was trying to execute [note description], which is what it does to 
get a description to display as a result of 'po note'. Normally, the standard 
'description' in NSObject is called, which just prints the address of the 
object and its class. You, apparently have overridden 'description' in the Note 
class, and it apparently invokes 'category', which invokes 
'-[SRMainWindowController getEncryptionKey]', which invokes 'toggleLock:', 
which is why it hits the breakpoint again.

Note that (apparently) if isEncrypted is NO, then 'getEncryptionKey' isn't 
invoked, and so 'toggleLock' isn't invoked either. That's why setting 
isFlagged instead didn't crap out in the debugger.

Other than indicating an inappropriate design of your 'description' override, 
there's absolutely no indication of anything wrong here at all. It looks like 
you've been chasing a chimera. :)

Obviously I may be overlooking something, but step 1 is to fix your 
'description' method so that it doesn't cause Core Data fetches. 

 #4  0x7fff868a386b in _NSPrintForDebugger ()
 #5  function called from gdb
 #6  -[Note setIsEncrypted:] (self=0x20027bda0, _cmd=0x1000a6eb8, 
 value=0x7fff70886280) at Note.m:206
 #7  0x00010002d5c9 in -[SRMainWindowController toggleLock:] 
 (self=0x2000df5e0, _cmd=0x1000a9239, sender=0x2000867e0) at 
 SRMainWindowController.m:2897
 #8  0x7fff83b2afbf in -[NSToolbarButton sendAction:to:] ()
 #9  0x7fff8379c135 in -[NSToolbarItemViewer mouseDown:] ()
 #10 0x7fff8368934f in -[NSWindow sendEvent:] ()
 #11 0x7fff835bea86 in -[NSApplication sendEvent:] ()
 #12 0x7fff835554da in -[NSApplication run] ()
 #13 0x7fff8354e1a8 in NSApplicationMain ()
 #14 0x00016b60 in main (argc=1, argv=0x7fff5fbff628) at main.m:13

___

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