Re: Strange Strange Bug
Re: Strange Strange Bug
- Subject: Re: Strange Strange Bug
- From: Kai <email@hidden>
- Date: Sat, 6 Sep 2008 10:52:53 +0200
On 6.9.2008, at 02:10, Steve Cronin wrote:
Kai;
OK That seems reasonable but:
why do I not see this behavior anywhere else?
Yes, it surprised me a little, too, that I had never seen something
like this. Now if I am right, this occurs only if such a variable
happens to be at a location where another object pointer has
previously been, which has been deallocated in the meantime. And if
zombies are enabled, if I interpret your findings correctly. That may
explain it.
why have I never seen it before now?
Zombies not enabled? Pure luck?
why if I restart XCode does the 'bad' instance fall on exactly the
same string?
Because your program behaves reproducible and always does the same
things on the stack before calling the method in question.
Again, I am not 100% sure about this.
Kai
Thanks,
Steve
On Sep 5, 2008, at 4:11 AM, Kai wrote:
Steve,
looks like the debugger tries to inspect your uninitialized string
pointers. And it happens that the stack location assigned to the
6th string pointer still contains the address of a now deallocated
object left there when another method exited.
So this is a debugger-only problem and completely harmless without
debugger (if I am not mistaken, of course).
To fix it, assign nil to the string pointers when you declare them:
NSString *gAsOf = nil;
etc..
Or, better yet, do not declare the variables before using them
(that is, not all together at the start of the method). (Note that
this style may be only possible with certain C dialects. I use
Objective C++, therefore I’m not sure).
Hope this helps.
Kai
On 5.9.2008, at 09:04, Steve Cronin wrote:
Folks;
OK this behavior has me a little spooked...
This behavior occurs the first time through the method!
I have a breakpoint set at the first line of a method, which
happens to be a NSLog(@"Ready");
As is normal I have my local variable declarations at the
beginning of the method:
NSArray *myKeys, *workingValues;
NSString *gAsOf, *gAsOfDate, *gDataMask, *gDataMaskName, *gID,
*gIDName, *gVersion, *gVersionName;
gAsOfDateName = [[NSUserDefaults standardUserDefaults]
stringForKey:@"groupAsOfDatePropertyName"];
gDataMaskName = [[NSUserDefaults standardUserDefaults]
stringForKey:@"groupDataMaskPropertyName"];
Nothing surprising or complicated...
However, the console window will show at least two of these
messages:.
2008-09-05 00:56:45.101 XYZ[345:813] *** -[CFString _cfTypeID]:
message sent to deallocated instance 0x16d1db80
2008-09-05 00:56:45.563 XYZ[345:813] *** -[CFString _cfTypeID]:
message sent to deallocated instance 0x16d1db80
2008-09-05 00:56:46.776 XYZ[345:813] *** -[CFString _cfTypeID]:
message sent to deallocated instance 0x16d1db80
If I scroll the variables display at the upper right in the
debugger window, the console will add more of these messages.
One of the strings in the variable display will have its 'Value'
shown as the instance id shown in these messages.
For this string variable the 'Summary' will be empty as opposed to
all other 'Summary' which have 'Invalid'
The debugger is paused several lines above the declaration of this
variable...
If I merely switch the positions of the variables I can change
which variable has the 'bad' instance id.
It is always the 6th declared string variable.
I can mix up the order of variables, change the actual variable
names, or interleave NSArray declarations, it doesn't matter...the
6th string exhibits this behavior.
Hovering over the variable it displays the 'yellow help ribbon'
with 'NSZombie_CFString', whereas all the others are 'NSString'
Commenting out the declarations and use and compiling works fine.
Uncommenting brings back the exact behavior.
Note: If I take out the breakpoint then the console does NOT show
these messages even though I have left log messages in the method
so I know the method is being executed....
I have restarted XCode as well as the system (Intel 10.5.4, XC3.1)
no change
What in the heck is going on? Should I be worried? How can I shed
this anomaly?
Thanks,
Steve
_______________________________________________
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
_______________________________________________
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