Re: [Solved-kinda]: Is it me or XCode 1.2?
Re: [Solved-kinda]: Is it me or XCode 1.2?
- Subject: Re: [Solved-kinda]: Is it me or XCode 1.2?
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 30 Apr 2004 09:10:54 -0400
On Apr 26, 2004, at 5:55 PM, Jim Ingham wrote:
> The only thing I can think of is to make sure that there isn't another
> variable "node" that this one in the argument list was shadowing? A
> global or something? That would explain the differing behavior when
> you change the name.
Not in this case it wouldn't, unless he only changed the variable name
is some places. While shadowing is bad practise, why would it matter if
the method never references the shadowed global or ivar?
More likely, "node" is being used in some cpp macro somewhere, if in
fact the string "node" is related to the problem.
>
> Other than that, this seems very bizarre.
>
> If you can produce two binaries, one with the "node" variable and one
> with the "n", and tell me where to set a breakpoint in both to get to
> this code, and how to run them to hit the breakpoint, then I can
> probably figure out what is going on. If you feel like doing this,
> than please do file a Radar with this info.
>
> Thanks,
>
> Jim
>
> On Apr 26, 2004, at 2:38 PM, Phil Curry wrote:
>
>> Nope... I'm positive, because I recall looking thru optimization
>> settings as a possible reason the debugger wasn't walking thru the
>> code in the order I expected. In fact I just changed the variable
>> name back to node from n and the same problem returns.
>>
>> An interesting observation is that when I get to the line:
>> if ( [n numChildren] > 0) {
>> the frame stack in the debugger, but if I change the n to node:
>> if ( [node numChildren] > 0) {
>> the frame stack does not appear in the debugger!
>>
>> Curious.
>> -Phil
>>
>> On Apr 26, 2004, at 1:13 PM, Jim Ingham wrote:
>>
>>>
>>> Is there any chance that when you rebuilt you also touched some
>>> build option, particularly optimization level? Just changing the
>>> name of a variable shouldn't make any difference, but increasing the
>>> optimization level can both uncover subtle latent bugs in your code,
>>> and confuse the debugger mightly...
>>>
>>> Jim
>>>
>>> On Apr 26, 2004, at 11:57 AM, Phil Curry wrote:
>>>
>>>> Well I changed the name in setXforNode: from node to n
>>>> Now it steps thru with the debugger. Go figure! These are the
>>>> things that scare me1
>>>>
>>>> -Phil
>>>>
>>>>>> No... I don't think so as 'tNode' has a valid set of values at
>>>>>> the line
>>>>>> below marked by '<<<<<<'.
>>>>>> Again, if I run the code it runs, if I try to step thru it with
>>>>>> the
>>>>>> debugger, I get the error.
>>>>>
>>>>> Ahh, but you recursively execute setXForNode, and are your sure
>>>>> that
>>>>> everything in the node is set correctly?
>>>>>
>>>>> --
>>>>> Glenn L. Austin <><
>>>>> Computer Wizard and Race Car Driver
>>>>> <email@hidden>
>>>>> <http://www.austin-home.com/glenn/>
>>>> _______________________________________________
>>>> 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.
>>>>
>>>>
>>> --
>>> Jim Ingham email@hidden
>>> Developer Tools
>>> Apple Computer
>>>
>>
>>
> --
> Jim Ingham email@hidden
> Developer Tools
> Apple Computer
> _______________________________________________
> 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.
>
>
--
Brent Gulanowski email@hidden
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.