I have the following piece of code:
NSString *tempString = [[NSString alloc] initWithFormat:#"%d/%d/%d",day, month, year];
dateString = tempString;
[tempString release];
NSLog(#"retain count for datstring and tempstring is %d and %d",[dateString retainCount],[tempString retainCount]);
NSLog(#"%# and %#",dateString, tempString)
Now it prints the retain count of tempString as 1 (also dateString retain count = 1) even though I am releasing it in the line before. Also the NSlog statement printing the two strings doesn't display anything. Im assuming this is because, since by my code, dateString is pointing to the location of tempString and tempString has been released, NSlog will be unable to print the string. But then why is the retain count of tempString = 1?
If i replace the line
dateString = tempString;
with
dateString = [NSString stringWithString: tempString];
then the NSlog statement prints the values of both dateString and tempString and displays their retain counts as 1. How is the value of tempString getting printed when i am releasing it in the previous line?
Read the iphone documentation:
You should not use retainCount to
debug memory management issues.
As jamapag states release simply tells the runtime to run dealloc meaning that the memory is marked as reusable not that it has been cleared. For objects with a retainCount of 1, the runtime usually doesnt decrement the retainCount value after the dealloc.
Another thing to note is that you should not send messages to released objects as you are doing with retainCount you are bound to get some unexpected behaviours
When you send release to tempString the objc runtime simply calls dealloc. Just because an object has been sent dealloc doesn't mean its data on the heap is immediately destroyed. It's just marked for destruction later.
Related
I have built one 'deep' NSMutableDictionary that contains parsed XML data along with other relevant information that I can pass from one view controller to another. The NSMutableDictionary contains mostly NSStrings but also another NSMutableDictionary more NSStrings and finally followed even deeper with an NSMutableArray of custom objects (it's for a calendar).
Now, because it is a calendar, there are obviously dates involved. The XML data that I receive and parse using NSXMLParser returns strings, so it was on me to convert the day's date to usable numbers. The date in XML comes in with the following format: "MM.DD" I created the following method to do so:
- (void)createDateCodesWithString:(NSString *)string
{
NSInteger monthCode;
NSInteger dayCode;
....
NSArray *dates = [string componentsSeparatedByString:#"."];
monthCode = [[dates objectAtIndex:0] integerValue];
dayCode = [[dates objectAtIndex:1] integerValue];
....
shortDay = [NSNumber numberWithInt:dayCode];
}
'shortDay' is a NSNumber* and an ivar and set as a property (nonatomic, retain) for the custom object that I have created. When I run NSLog commands in the console, it appears that 'shortDay' and other data has been stored successfully in the deep NSMutableDictionary. I run in to problems, however, when I try to access the data again. When I access a NSString* stored ivar, things work OK, but when I attempt to access the NSNumber* I am given the error EXC_BAD_ACCESS with either code 1 or code 2. This is how I try to call upon the NSNumber*
NSNumber *number = day.shortDay;
return [number stringValue];
Might the problem be because the NSArray *dates strips the string into month and day strings and the day string, being two characters long, may contain a '0' before, say, a '6' if the day is the 6th of the month? Any advice?
I am happy to post more code if needed.
It's possible that the memory for shortDay is being cleaned up before the next time you try to access it. When assigning it, try this instead:
shortDay = [[NSNumber numberWithInt:dayCode] retain];
to increase the reference count (AKA take ownership of the object) to avoid the memory being deallocated too early.
If this resolves the problem, you will then need to call [shortDay release] in the dealloc method of your class, such that the memory for it will be properly deallocated at the right time.
I realize this question may sound dumb, but just bear with me. I built an app to help new developers wrap their head around memory retention on the iPhone (no ARC yet). It is plain and simple, 4 buttons, init, access, retain, and release. Pretty self explanatory. I am displaying what the retain count for my string object that is the target of our poking and prodding. (Please no lectures on use of [myVar retainCount], I already know)
This stuff will never make it into actual apps, just toying with it for fun and hopefully help someone learn how memory works. My retain and release all work great. My question is that why does my retain count drop back to 1 if I call myString = [[NSMutableString alloc] init]; again. I can boost my retain count to 40, but after calling alloc/init I go back to zero. I am not leaking anywhere, just curious what happens to myString if/when alloc/init is called on it again.
My question is that why does my retain count drop back to 1 if I call
myString = [[NSMutableString alloc] init]; again?
Because you are failing to understand a very basic concept of Objective-C; myString is not an instance of an NSMutableString, but a reference to an instance. If you were to:
myString = [[NSMutableString alloc] init];
myString = [[NSMutableString alloc] init];
You now have two instances of NSMutableString, one leaked.
If you:
myString = [[NSMutableString alloc] init];
otherString = myString;
You now have a single instance of NSMutableString with two references.
In all three allocations, the NSMutableString instance will have a +1 retain count and, thus, you must balance each with a single release or you'll leak.
Treating retain counts as an absolute count is a path to madness. Or, at best, the scope of usefulness of the absolute retain count is so limited that learning about it is not applicable to real world iOS programming.
This bears repeating:
The retainCount of an object is tricky business.
If you were to continue down this path, you should be aware of the following details:
retainCount can never return 0
messaging a dangling pointer is not guaranteed to crash
retain count cannot be known once you have passed an object through any system API due to implementation details
any subclass of any system class may have an unknown retain count due to implementation details
retain count never reflects whether or not an object is autoreleased
autoreleases is effectively thread specific while the retain count is thread global
some classes are implemented with singletons some of the time (NSString, certain values of NSNumber)
the implementation details change from platform to platform and release to release
attempting to swizzle retain/release/autorelease won't work as some classes don't actually use those methods to maintain the retain count (implementation detail, changes per platform/release, etc..)
If you are going to teach retain/release, you should be treating the retain count as a delta and focus entirely on "If you increase the RC, you must decrease it".
when you call myString = [[NSMutableString alloc] init];, you're not "calling alloc/init on it again". You're not calling a method on the same instance you had. You're allocating and initializing a new instance, a completely different object from the one you had before.
And if you're doing that with a variable that had an object that you retained, then yes, you are leaking it.
Try this.
NSString *myString = [[NSMutableString alloc] init];
NSLog(#"%d", [myString retainCount]); // "1"
for (int i = 1; i < 40; i++)
[myString retain];
NSLog(#"%d", [myString retainCount]); // "40"
NSString *backup = myString;
myString = [[NSMutableString alloc] init];
NSLog(#"%d", [myString retainCount]); // "1"
NSLog(#"%d", [backup retainCount]); // "40"
You see, you have a different object with a new retain count. Your original object still exists and still has the same retain count. Assignment changes the object a variable refers to. A variable doesn't have a retain count, an object does.
myString = someOtherString;
NSLog(#"%d", [myString retainCount]); // who knows?
With retained property:
self.iString = backup;
NSLog(#"%d", [self.iString retainCount]); // "41" - 1 more because property retained
NSString *newString = [[NSMutableString alloc] init];
NSLog(#"%d", [newString retainCount]); // "1"
self.iString = newString;
// 1 for alloc 1 for retain (in real code you should release newString next)
NSLog(#"%d", [self.iString retainCount]); // "2"
NSLog(#"%d", [backup retainCount]); // "40" - self.iString released it
After trying to print retainCount of object I get 2147483647. Why do I get such a result? It should be 1, shouldn't?
NSString *myStr = [NSString new];
NSUInteger retCount = [myStr retainCount];
NSLog(#"refCount = %u", retCount);
2011-09-08 17:59:18.759 Test[51972:207] refCount = 2147483647
I use XCode Version 4.1. Tried compilers GCC 4.2 and LLVM GCC 4.2 - the same result.
Garbage Collection option was set to unsupported.
NSString is somewhat special when it comes to memory management. String literals (something like #"foo") are effectively singletons, every string with the same content is the same object because it can't be modified anyway. As [NSString new] always creates an empty string that cannot be modified, you'll always get the same instance which cannot be released (thus the high retainCount).
Try this snippet:
NSString *string1 = [NSString new];
NSString *string2 = [NSString new];
NSLog(#"Memory address of string1: %p", string1);
NSLog(#"Memory address of string2: %p", string2);
You'll see that both strings have the same memory address and are therefore the same object.
This doesn't directly answer your question, but retainCount is not really all that useful and should not be used for testing. See this SO post for details.
When to use -retainCount?
While NSString's are an odd case (there are others in the framework) you might also run across this in other clases - it's one of the ways of creating a singleton object.
A singleton only exists once in the app and it's pretty important that it never gets released! Therefore, it will overwrite some methods of NSObject including (but not limited to):
- (id)release {
// Ignore the release!
return self;
}
- (NSUInteger)retainCount {
// We are never going to be released
return UINT_MAX;
}
This object can never be released and tells the framework that it's a singleton by having a ludicrously high retain count.
Checkout this link for more information about singleton objects.
I've seen this a couple of times regarding NSStrings, the retainCount returns the maximum count instead of the actual one when you try to look at retainCounts of strings in this manner.
Try this;
NSString *myStr = [[NSString alloc] init];
NSUInteger retCount = [myStr retainCount];
NSLog(#"refCount = %u", retCount);
Edit: Restored NSUInteger
#define kTestingURL #"192.168.42.179"
...
NSString *serverUrl = [[NSString alloc] initWithString:
[NSString stringWithFormat:#"http://%#", kTestingURL]];
NSLog(#"retain count: %d",[serverUrl retainCount]);
Why is the retain count 2 and not 1?
Yes, You will get retain Count 2, one for alloc and other for stringWithFormat. stringWithFormat is a factory class with autorelease but autorelease decreases retain count in the future.
You shoud not care about the absolute value of the retain count. It is meaningless.
Said that, let's see what happens with this particular case. I slightly modified the code and used a temporary variable to hold the object returned by stringWithFormat to make it clearer:
NSString *temp = [NSString stringWithFormat:#"http://%#", kTestingURL];
// stringWithFormat: returns an object you do not own, probably autoreleased
NSLog(#"%p retain count: %d", temp, [temp retainCount]);
// prints +1. Even if its autoreleased, its retain count won't be decreased
// until the autorelease pool is drained and when it reaches 0 it will be
// immediately deallocated so don't expect a retain count of 0 just because
// it's autoreleased.
NSString *serverUrl = [[NSString alloc] initWithString:temp];
// initWithString, as it turns out, returns a different object than the one
// that received the message, concretely it retains and returns its argument
// to exploit the fact that NSStrings are immutable.
NSLog(#"%p retain count: %d", serverUrl, [serverUrl retainCount]);
// prints +2. temp and serverUrl addresses are the same.
You created a string and then used it to create another string. Instead, do this:
NSString *SERVER_URL = [NSString stringWithFormat:#"http://%#", kTestingURL];
this is because you [[alloc] init] a first NSString so serverUrl have retain +1 and at the same line you call [NSString stringWithFormat] that return another nsstring on autorelease with retain count at 2
you should only use the :
NSString *serverUrl = [NSString stringWithFormat:#"http://%#", kTestingURL];
so your serverUrl will have retainCount to 1 and you don't have to release string
Whenever I read about how to avoid memory leaks, I always came across a concept that
"Number of alloc must be equal to number of release".
But I came across a concept where we require more than one release. Like What I used to practise was as follows:
(NSString*) func1
{
NSString* result = [[NSString alloc] initWithFormat:#"Test String"]];
return result;
}
(void) func2
{
NSString* temp = [self func1];
[temp release];
}
But I came across a concept of retain count which says that in the above case the memory is not deallocated for the string since the retain count for the string is 1 at the end. So the right practise is
(NSString*) func1
{
NSString* result = [[NSString alloc] initWithFormat:#"Test String"]];
[result autorelease];
return result;
}
(void) func2
{
NSString* temp = [self func1];
[temp release];
}
So now I have two releases for deallocating the memory which is a contradictory to my above sentence which I read on most of the blogs ""Number of alloc must be equal to number of release".
I am little bit confused about the above stuff. Becoz if I autorelease the string in the first function and want to use the string in second function for a long time, and what if the release pool is flushed in between, on the other side if I dont use autorelease it will still block the memory.
So whats the correct way of doing it.
At the time you call alloc whatever is returned will have a retainCount of 1. Calling release on that object will cause it to be deallocated (it's retainCount will drop to 0). In your first example, then, the second line of func2 will deallocate the NSString* you received from func1, and your memory management chores are complete.
In the second example you are tossing result in func1 into the current autorelease pool, which will cause it to become deallocated when the pool drains. You do not want to attempt to manage the memory of that object once it has been placed into the pool- it is no longer your responsibility.
If you want to generate the string and keep it around for a while (e.g., through the lifetime of several autorelease pools), I would recommend the first form of memory management.
The correct way is this:
(NSString*) func1 {
NSString* result = [[NSString alloc] initWithFormat:#"Test String"];
// retaincount == 1
return [result autorelease];
}
(void) func2 {
NSString* temp = [self func1];
// retaincount == 1
// temp is autoreleased, therefore no [release] is necessary.
}
Autorelease is automatically done at the end of the run loop, that means it cannot be emptied while your code is doing something. -> The code you have is safe. This isn't true for multithreaded application!
(NSString*) func1
{
NSString* result = [[NSString alloc] initWithFormat:#"Test String"]];
return result;
}
[result retainCount] is 1
(void) func2
{
NSString* temp = [self func1];
[temp release];
}
[temp retainCount] is 0
No need for autorelease.
From Memory Management Rules:
This is the fundamental rule:
You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.
The following rules derive from the fundamental rule, or cope with edge cases:
As a corollary of the fundamental rule, if you need to store a received object as a property in an instance variable, you must retain or copy it. (This is not true for weak references, described at “Weak References to Objects,” but these are typically rare.)
A received object is normally guaranteed to remain valid within the method it was received in (exceptions include multithreaded applications and some Distributed Objects situations, although you must also take care if you modify the object from which you received the object). That method may also safely return the object to its invoker.
Use retain in combination with release or autorelease when needed to prevent an object from being invalidated as a normal side-effect of a message (see “Validity of Shared Objects”).
autorelease just means “send a release message later” (for some definition of later—see “Autorelease Pools”).
In general, I'd feel safer to do a retain on a return value, like the one in the "func 2":
(NSString*) func1 {
NSString* result = [[NSString alloc] initWithFormat:#"Test String"];
return [result autorelease];
}
(void) func2 {
NSString* temp = [[self func1] retain];
// Do something with temp
[temp release];
}
Is this unnecessary? I understand that in this example "temp" is just a local variable. But it could have been an instance variable, which may need to be retained.