Strange Clang behaviour in Xcode 8.3 - ios

Question

Recently i noticed strange behaviour with Objective C memory management in Xcode.
Here is the code:
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
NSString *firstString = [[NSString alloc] initWithString: #"Hello"];
NSString *secondString = firstString;
[firstString release];
NSLog(#"%#", secondString);
}
return 0;
}
I think, that secondString points to nil after releasing firstString and NSLog should produce error.
But this code does not produce any errors and successfully prints "Hello" string.
I manually compiled and run code with such command and does not noticed any errors too:
% clang -framework Foundation -fno-objc-arc main.m && ./a.out
I tried to compile this code with online objective-c compiler (GCC) (http://rextester.com/l/objectivec_online_compiler) and error was occurred.
What am i doing wrong?
ARC support is turned off in Xcode.
Thanks in advance.

Answer 1

If you perform a static analysis (shift+command+B in Xcode, or "Analyze" on Xcode's "Product" menu), it will warn you that you're trying to reference an object after it is released:
The issue is that in manual reference counting code, your references to deallocated objects are not set to nil automatically. So you can end up with dangling pointers to an object that was previously deallocated unless you manually nil those pointers.
The static analyzer is remarkably good at identifying these sorts of issues, amongst others. I would advise making sure you have a clean bill of health from the static analyzer before moving on.
The second line of defense in situations like this is to enable the zombies runtime debugging option. This will report any attempts to interact with objects after they've been deallocated. Zombies can be enabled in the "Diagnostics" section when you edit your Xcode target's scheme.
Unfortunately, you are using NSString, which doesn't follow the typical memory management rules (it can keep its own references to strings, so they're not always deallocated when you'd otherwise expect them to be).
Consider an example similar to yours, except with a custom class:
#import <Foundation/Foundation.h>
#interface MyObject: NSObject
#end
#implementation MyObject
#end
int main(int argc, const char * argv[]) {
#autoreleasepool {
MyObject *firstObject = [[MyObject alloc] init];
MyObject *secondObject = firstObject;
[firstObject release];
NSLog(#"%#", secondObject);
}
return 0;
}
If you run this with zombies on, you'll get a corresponding error message indicating that you're trying to interact with a deallocated instance:
2017-05-27 08:19:18.154033-0700 MyApp[36888:7215135] *** -[MyObject isProxy]: message sent to deallocated instance 0x100303620
But you may not get this warning from NSString. Bottom line, one should avoid drawing any broader memory management conclusions from NSString behavior. Instead, rely upon Xcode's static analyzer and zombies. (Note, remember to turn off zombies when you're done debugging your app.)