[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 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
