Re: 'selector not recognized' ?
Re: 'selector not recognized' ?
- Subject: Re: 'selector not recognized' ?
- From: Jim Ingham <email@hidden>
- Date: Thu, 22 Jul 2004 13:02:58 -0700
The stack on PPC is a contiguous piece of memory, and as you push & pop
frames, the stack pointer just moves up & down in this memory area. So
if you push a frame, make some local objects, pop that frame & push a
new frame, uninitialized local data will generally point to stuff left
over from the previous frame's locals.
GDB & Xcode between them try to keep calling the data formatter
functions from causing trouble, for instance if the function call
crashes, gdb is able to clean up after it. But unfortunately, we don't
catch an error that throws an NSException or a C++ exception or just
longjmp's. That will unwind past the function call we were making, and
usually past alot of your code as well, and causes much wailing &
gnashing of teeth... We have a bug for this.
The only way to work around this at present is to turn off the data
formatters. Then you don't get the fancy customized display, but at
least you can debug. Do this with the Custom Data Formatters option
under the Debug menu. Then you can use "po" in the gdb console (or the
context menu in the Variable display") to print the objects you care
about.
Jim
On Jul 22, 2004, at 12:06 PM, Fritz Anderson wrote:
My impression of RISC code generation was that "the stack," as a frame
for local variables, is something of a useful myth preserved in the
coder's mental pdp11, rather than a stretch of actual,
expensive-to-access, real estate. I could be wrong.
Uninitialized variables (as opposed to shared ones) could explain at
least some what I've seen. I think, however, I remember the gdb bug in
the OP being absent at one line in a target function, and present the
next, without an external call intervening; which is consistent with
shared, rather than uninitalized memory.
-- F
On 22 Jul 2004, at 1:08 PM, Shawn Erickson wrote:
On Jul 22, 2004, at 10:20 AM, Fritz Anderson wrote:
NSView * myParent = [self superview];
// Do things with myParent
// Stop doing things with myParent
NSString * scratch;
[scanner scanString: @"foo" intoString: &scratch];
Both myParent and scratch will appear in the debugger's list of
local variables, even though the same storage (or, likelier,
register) is allocated to both. The debugger, being whizzy, tries to
display the string value of scratch. But in the early part of the
function, that register is filled with a pointer to an NSView, which
doesn't respond to messages like "length". Whereupon the debugger
belches loudly (*** -[NSView length]: selector not recognized) and
refuses to be useful any more.
In an unoptimized executable (not compiler optimized) while in the
same block of code myParent and scratch variables will be held in
different memory slots on the stack, they will not share the same
storage (even in optimized code they likely will be held in different
slots).
Now both myParent and scratch pointers could point to the same
location in memory either because on isn't initialized, explicit
assignment, or the memory location they point at got reused.
I personally have not seen, at least noticed, the debugger issue you
outline above when debugging an unoptimized executables but if it
exists and prevents further use of the debugger in that session make
sure to file a defect about it.
-Shawn
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.