Re: 'selector not recognized' ?
Re: 'selector not recognized' ?
- Subject: Re: 'selector not recognized' ?
- From: Fritz Anderson <email@hidden>
- Date: Thu, 22 Jul 2004 14:06:14 -0500
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.