On Jun 25, 2009, at 02:34, Tristan Celder wrote:
I'm extremely new to Cocoa programming but have come across a
problem where I am getting a [NSConcreteAttributedString
initWithString:] called with nil string argument. pop up in my
console. I have had it once before and managed to track it down to a
NumberFormatter with no symbols set for nil/null values. This
problem was the cause of a far more serious problem which was a very
bizarre error which breaks my core data bindings for any table view
displaying exactly one row of an attribute fetched via a
relationship when a document is reopened after save.
Unfortunately the console warnings have begun popping up again, and
this time I have absolutely no idea where/who/what could be causing
them in my interface. (It's only when I do a clean build that they
show up in the first place). So... what I would really like to know
is how I can find the source of these messages. A previous post I
dug up, simply mentions that one can "test the location on the stack
which holds the parameter." which can be done using the syntax
"*(id*)($ebp + 16)".
Now, as I'm new to cocoa development (And C in general), my
knowledge of gdb is limited. How would I set this breakpoint from
xcode?
When you ask questions about errors logged on the console, you'll get
a much more helpful response if you paste the exact text of the
message in your post. :)
It sounds like the "console warnings" you're seeing are in fact
exceptions -- which are very far from being warnings. When you see an
exception logged, your application has pretty much shot itself in the
foot, and you can't expect execution to continue correctly.
To stop in the debugger at an exception, set a symbolic breakpoint at
(if you're using 10.5) 'objc_exception_throw' -- open the breakpoint
window (Command-Option-B, probably), double-click where it says
"Double-click for symbol', type in that symbol name and press Return.
(Leave that breakpoint in, um, forever.)
Run your application with "Build and Debug" (instead of "Build and
Run"), and it'll stop in the debugger when the exception occurs. You
can then examine the backtrace in the debugger window to see where in
your code the exception occurred, and how you got there.
_______________________________________________
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
