Why doesn't this crash?
I'm attempting to narrow down a bug to a minimum reproducible case and found something odd.
Consider this code:
static NSString *staticString = nil;
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
if (staticString == nil) {
staticString = [[NSArray arrayWithObjects:@"1", @"2", @"3", nil] componentsJoinedByString:@","];
}
[pool drain];
NSLog(@"static: %@", staticString);
return 0;
}
I'm expecting this code to crash. Instead, it logs:
2011-01-18 14:41:06.311 EmptyFoundation[61419:a0f] static: static:
However, if I change the NSLog()
to:
NSLog(@"static: %s", [staticString UTF8String]);
Then it does crash.
edit a bit more info:
After draining the pool:
NSLog(@"static: %@", staticString); //this logs "static: static: "
NSLog(@"static: %@", [staticString description]); //this crashes
So apparently invoking a method on the string is good enough to get it to crash. In that case, why doesn't logging the string directly cause it to crash? Shouldn't NSLog()
be invoking the -description
method?
Where is the second "static: " coming from? Why isn't this crashing?
Results:
Both Kevin Ballard and Graham Lee are correct. Graham's correct in realizing that NSLog()
is not invoking -description
(as I was erroneously assuming), and Kevin is almost definitely correct that this is a weird stack-related issue with copying a format string and a va_list
around.
NSLogging
andNSString
does not invoke-description
. Graham elegantly showed this, and if you trace through the Core Foundation sources that do the logging, you'll see that this is the case. Any backtrace originating insideNSLog
shows that it invokesNSLogv
=>_CFLogvEx
=>_CFStringCreateWithFormatAndArgumentsAux
=>_CFStringAppendFormatAndArgumentsAux
._CFStringAppendFormatAndArgumentsAux()
(line 5365) is where all of the magic is going on. You can see that it's manually going through to find all the%
substitutions. It only ends up invoking the description copy function if the type of the substitution is aCFFormatObjectType
, the description function is non-nil, and the substitution hasn't already been handled by another type. Since we've shown that the description is not getting copied, it's reasonable to assume that anNSString
gets handled earlier (in which case it's probably going to be doing a raw byte copy), which leads us to believe...- There's a stack error going on here, as Kevin surmises. Somehow the pointer that was pointing to the autoreleased string is getting substituted to a different object, which happens to be an
NSString
. So, it doesn't crash. Weird. However, if we change the type of the static variable to something else, like anNSArray
, then the-description
method does get called开发者_JS百科, and the program does crash as expected.
How truly and utterly strange. Points go to Kevin for being the most correct about the root cause of the behavior, and kudos to Graham for correcting my fallacious thinking. I wish I could accept two answers...
My best guess for what you're seeing is that NSLog() copies the format string (probably as a mutable copy), and then parses the arguments. Since you've dealloc'd staticString
, it just so happens that the copy of the format string is being placed into the same location. This is causing you to see the "static: static: "
output that you described. Of course, this behavior is undefined - there's no guarantee it will always use the same memory location for this.
On the other hand, your NSLog(@"static: %s", [staticString UTF8String])
is accessing staticString
before the format string copy happens, which means it's accessing garbage memory.
Your assumption that NSLog()
calls -description
on an NSString
instance is faulty. I just added this category:
@implementation NSString (GLDescription)
- (NSString *)description {
NSLog(@"-description called on %@", self);
return self;
}
@end
It doesn't cause a stack overflow, because it doesn't get called recursively. Not only that, but if I insert that category into the code in your question, I find this output:
2011-01-18 23:04:11.653 LogString[3769:a0f] -description called on 1
2011-01-18 23:04:11.656 LogString[3769:a0f] -description called on 2
2011-01-18 23:04:11.657 LogString[3769:a0f] -description called on 3
2011-01-18 23:04:11.658 LogString[3769:a0f] static: static:
so we conclude that NSLog()
doesn't call -description
on an NSString
it comes across in its args. Why you get the static string twice is likely a quirk of the data on the stack when you erroneously access the released staticString
variable.
Accessing dealocated memory does not necessarily cause a crash. The behavior is undefined. You are expecting too much!
Maybe it has something to do with the @"static:" being stored in the same memory location as staticString. staticString will be deallocated and it stores the @"static: %@" in that recycled mem location, so then the staticString pointer is on "static: %@" so it ends up static: static:.
This is a case of "Use after free()
". What happens is "undefined behavior". Your example is really no different than:
char *stringPtr = NULL;
stringPtr = malloc(1024); // Example code, assumes this returns non-NULL.
strcpy(stringPtr, "Zippers!");
free(stringPtr);
printf("Pants: %s\n", stringPtr);
What happens at the printf
line? Who knows. Anything from Pants: Zippers!
to Pants: (...garbage...) Core Dump
.
All the Objective-C specific stuff is actually irrelevant- it's the fact that you're using a pointer to memory which is no longer valid is the only thing that matters. You're better off throwing darts at the wall than trying to explain "why" it's not crashing and printing static: static
. For performance reasons, most malloc
implementations don't bother "reaping" free()
'd allocations until they have to. IMHO, this is probably why your example isn't crashing in the way you were expecting it to.
If you really want to see this particular program crash, you can do one of the following:
- Set the environment variable
CFZombieLevel
to17
(scribble + don't free). - Set the environment variable
NSZombieEnabled
toYES
. - Set the environment variable
DYLD_INSERT_LIBRARIES
to/usr/lib/libgmalloc.dylib
(seeman libgmalloc
).
精彩评论