Re: Debugging a NibLoad binding error
Re: Debugging a NibLoad binding error
- Subject: Re: Debugging a NibLoad binding error
- From: Steve Cronin <email@hidden>
- Date: Tue, 8 Jan 2008 21:59:49 -0600
mmalc & Alastair;
I don't mean to be petulant or thick headed but I've still got
"issues"...
mmalc;
Thanks for the links to Apple docs but I am still using Tiger & XC2.4.
The latest version of XCUG that I can find in my personal archives is
2.2.
Was there a later version? Is it still available?
BTW: When I use the XCode Help on my Tiger machine and follow the
embedded .pdf links which specifically state 'XCode2UG' it takes me
to the XC3UG...
You say below that I have a model object that has a scalar attribute
that I have not implemented setNilForKey and presumably I know which
that is.
Well that is exactly the WRONG presumption. I have dozens of
objects, CoreData objects, overridden tableViews, windowControllers,
arrayControllers, etc as well as number of custom application
objects. They all have scalar attributes and I make extensive use of
bindings. I also have a reasonable reliance on NSUserDefaults.
I do NOT know where the error is arising. Alastair points out that it
is probably in the main.nib. I have >50 items in that nib and many
of them are reasonably dense from a user widget point of view! Your
admonishment to 'implement setNilForKey ' simply does not reflect the
reality of this project. It is hardly a quick 'cut and paste'...
Is it really necessary to go through this level of change to the
application of find this one issue?
You cite a section of the gdb docs below as a reference to how to set
a break on setNilForKey but I just can't make the connection. I have
read it over and I dont't see any correspondence. Is this catchpoint
or a watchpoint? Is it an rbreak command line instruction only? The
correspondence between what is written in the gdb doc's and best
practices for using XCode are simply NOT apparent (at least to me).
Using XCode 2.4 I have set both global and application symbolic break
points for:
setNilValueForKey
[NSObject setNilValueForKey]
- [NSObject setNilValueForKey]
+ [NSObject setNilValueForKey]
none of them ever fire.
Please, can you be a bit more detailed and specific about how to set
up this breakpoint?
Alastair;
You state the just the breakpoint on szone_error is all that is
needed to trap the 'double-free'. I have tried several incantations
and the exception just never fires.
All I see is this in the console output:
XYZ(7577,0xa000d000) malloc: *** error for object 0x1a6e2c90: double
free
XYZ(7577,0xa000d000) malloc: *** set a breakpoint in szone_error to
debug
to be clear I am using XC 2.4 and clicking on the add symbolic
breakpoint in the debugger window and typing 'szone_error'. I have
tried this as both app level and global level breakpoint. I've tried
just 'szone' alone as well as all upper case.
Also just curious why you think I could not use the disclosure
triangle to set a debugger action on this breakpoint (IF if would
ever fire).
It feels to me like my symbolic breakpoint are ALL failing. Maybe I
am just doing something wrong.
I learn most quickly by following working examples... but I can't
find any....
Anyway thanks for your time and patience!
Steve
On Jan 8, 2008, at 10:53 AM, mmalc crawford wrote:
On Jan 8, 2008, at 8:18 AM, Steve Cronin wrote:
mmalc;
OK I see that but which object? Which Nib is loading? How do I
figure this out?
My basic question is how do I use the debugger to help me find out
this kind of information.
Can I enter something useful (a debugger command?) in the
breakpoint window
What would I 'po' in the console window in order to make headway?
What is the best source of a document along the lines of 'how to
use the XCode Debugger: 20 case studies'?
Well, the Xcode User Guide would probably be a good place to start:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
XcodeUserGuide/Contents/Resources/en.lproj/06_02_db_set_up_debug/
chapter_42_section_1.html#//apple_ref/doc/uid/TP40002699-BABDECGI>
Then perhaps the GDB documentation:
<http://developer.apple.com/documentation/DeveloperTools/gdb/gdb/
gdb_toc.html>
particularly, say:
<http://developer.apple.com/documentation/DeveloperTools/gdb/gdb/
gdb_6.html#SEC31>
so that you can break on setNilValueForKey:.
But this all seems to be the secondary consideration.
At first glance, as noted in the previous reply, you have a model
objet that has a scalar attribute and you haven't implemented
setNilValueForKey:. Presumably you know which that is. So the
first thing to decide would be, what should be the behaviour on
setting nil? Is this a situation you want to allow for? In which
case implement setNilValueForKey: and your troubles should be
over. If you don't want to allow for it, then proceed to step b.
And if you don't want to work through the debugger documentation
just yet, you could still implement setNilValueForKey: for relevant
classes so that they print out information about the receiver...
mmalc
I have a 'double free - set breakpoint in szone_error' which is
eluding me.
In pursuit of this I have set a global breakpoint for both
'szone_error' and [NSException raise].
Is this the right thing to do?
Well just szone_error is needed to catch your double free. By adding
the other breakpoint, you've actually caught another problem.
When I attempt to launch now I get the stack shown below when I
land in the debugger.
How do I go about figuring out where this is occurring?
You've already answered that question yourself:
I can tell its a binding error in a nib. Which nib?
How do I get the Object and KeyPath out of line #8?
It's a little tricky because you don't have full debug symbols for
that code (and I don't think Apple provides debug symbols for the
Cocoa frameworks as a separate download...), so GDB doesn't know the
names or stack frame offsets of the parameters. However, the
exception itself probably contains the name of the thing that it
can't bind, and by default exceptions result in log output, so just
letting the code continue will probably give you some more information.
It *is* possible to read the code to find the address of the NSString
containing the nib file name, or to find the arguments in frame 8.
But you need to be confident at reading (and correctly interpreting)
assembly code on whichever architecture you're debugging and it can
get a little involved.
Incidentally, as to which nib file you need to look in, I think it's
probably your main nib file. Why do I say that? Because the nib
file causing the trouble is being loaded by NSApplicationMain(), not
from a user function or method.
Can I enter something useful (a debugger command?) in the
breakpoint window
No, but you can enter debugger commands in the console window.
What is the best source of a document along the lines of 'how to
use the XCode Debugger: 20 case studies'?
I don't know of one, but then I was already familiar with GDB.
As to what you should do next, if it was my program, I think I'd let
the exception fire and check the log window to see what it said. It
almost certainly includes information about which key it can't set,
which should give you a big clue. Cocoa is quite good at outputting
useful information in exceptions, so it's often a good idea to start
there.
_______________________________________________
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