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 0x000000010002dae9 in -[SRMainWindowController getEncryptionKey] > (self=0x2000df5e0, _cmd=0x1000a7210) at SRMainWindowController.m:2948 > #2 0x00000001000098d2 in -[Note category] (self=0x20027bda0, > _cmd=0x7fff85450184) at Note.m:257 > #3 0x00000001000089c8 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 0x00007fff868a386b in _NSPrintForDebugger () > #5 <function called from gdb> > #6 -[Note setIsEncrypted:] (self=0x20027bda0, _cmd=0x1000a6eb8, > value=0x7fff70886280) at Note.m:206 > #7 0x000000010002d5c9 in -[SRMainWindowController toggleLock:] > (self=0x2000df5e0, _cmd=0x1000a9239, sender=0x2000867e0) at > SRMainWindowController.m:2897 > #8 0x00007fff83b2afbf in -[NSToolbarButton sendAction:to:] () > #9 0x00007fff8379c135 in -[NSToolbarItemViewer mouseDown:] () > #10 0x00007fff8368934f in -[NSWindow sendEvent:] () > #11 0x00007fff835bea86 in -[NSApplication sendEvent:] () > #12 0x00007fff835554da in -[NSApplication run] () > #13 0x00007fff8354e1a8 in NSApplicationMain () > #14 0x0000000100006b60 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
