Re: Core Data debugging
Re: Core Data debugging
- Subject: Re: Core Data debugging
- From: email@hidden
- Date: Wed, 15 Jul 2009 19:14:10 -0400
Hello,
On 14 Jul 2009, at 10:01 PM, Fritz Anderson wrote:
> On 14 Jul 2009, at 5:14 PM, Tim Mowlem wrote:
>> BOOL result = [moc save: &err];
..
>> The problem is that every time I call this method the result is NO
>> implying a failure when saving.
..
>> The issue for this post is that when I try to examine the NSError
>> object it is invalid. The NSError is being created as the debugger
>> shows an address for the object but its field are not set.
>> Specifically the _code field had a variable value implying it was
>> not specifically set, and the?_domain field was "Invalid".
> Inspecting the instance variables of an NSError (or any other Cocoa
> object, for that matter) won't likely get you very far.
> Using the debugger, step past the save:, then type "po err" at the
> debugger console. That will get you a human-readable summary of the
> error, but not enough detail. However, that summary will include the
> address of the NSError's userInfo dictionary. Say the address is
> 0x123456; type "po (id)0x123456" into the console. You will be
> presented with a dump of the dictionary, from which you can (probably)
> glean the details of what went wrong.
Thank you for your reply Fritz. I am sorry but I did not make myself clear in my original post.
If you try and print object using po it throws an exception. The console output from gdb was:
2009-07-15 23:47:19.684 BookmarkManager[298:5ab3] ### saveBookmarkData called
[Switching to process 298 thread 0x5ab3]
[Switching to process 298 thread 0x5ab3]
(gdb) po err
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x922e668c in objc_msgSend ()
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off"
Evaluation of the expression containing the function (_NSPrintForDebugger) will be abandoned.
(gdb)?
I agree that printing the objects on the console via the gdb prompt is the best bet, but when debugging
it is often quicker to move the cursor over a variable and read the tooltip that appears at least for
strings and numbers. When the tooltip appears a menu is available the first item of which is Print Description
which seems to do the same job as "po" although I would be happy to know if that is true or whether po is better.
So the problem is that trying to po the NSError leads to a failure, which is why I surmised that the error was not?
properly initialized. The userInfo dictionary instance is nil for example in the NSError which may be what is causing the problem.
Anyway my original question still remains - how is one to debug this problem given the lack of info from the system?
> (You might have a look into your mail client; it's inserting a
> distracting amount of extraneous white space.)
Yes unfortunately I only have access to webmail during the week and the client seems to adds lots of whitespace.
Thank you,
Tim Mowlem
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden