I have an allocated object where its attributes are store in the following memory places:
When I make a simple attribution of the NSDate attribute to a variable it gives me an EXEC_BAD_ACESS.
As you can see from the first image only the date attribute and the fileDate variable have different addresses.
Am I making some pointer related error?
The other 2 attributes are assigned correctly to the variables, it only happens with the NSDate so maybe I'm missing some detail about NSDate.
EDIT1
DownloadFile definition:
EDIT2
init function:
EDIT3
date parameter:
Is there any reason why you are not using ARC? There are quite a few memory management errors there causing leaks and one that should cause your crash.
NSDate *dateFromString = [dateFormatter dateFromString:receivedDate];
returns an autoreleased NSDate so when you then call the additional
[dateFromString autorelease];
you are overreleasing the NSDate hence your crash.
[pFile setDate:[[NSDate alloc] init]];
is a memory leak. Going through the setter setDate: will cause pFile to take a +1 retain on the date, which it should release in it's dealloc. The [[NSDate alloc] init] call returns a date object with +1 but is then never released elsewhere.
You can fix this either with
[NSDate date]
Or
[[[NSDate alloc] init] autorelease];
The first option is preferred
Related
I am getting contact details and am having memory problems in my shouldContinueAfterSelectingPerson method. I followed a tutorial and did this weeks ago but now when I click Product -> Analyze I get 'Potential leak of an object allocated on line' on these 3 lines:
[lastName setText:(__bridge NSString *)ABRecordCopyValue(person, kABPersonLastNameProperty)];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateOfBirth setText:birthday];
When clicking on these errors I get (though only number 2 for the third line):
Call to a function 'ABRecordCopyValue' returns a Core Foundation object with a + 1 retain count
Object leaked: allocated object is not referenced later in this execution path and has a retain count of + 1
The full code is shown below:
- (BOOL)peoplePickerNavigationController: (ABPeoplePickerNavigationController *)peoplePicker shouldContinueAfterSelectingPerson:(ABRecordRef)person {
[firstName setText:(__bridge NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty)];
[lastName setText:(__bridge NSString *)ABRecordCopyValue(person, kABPersonLastNameProperty)];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"MMMM d, yyyy"];
birthday = [dateFormatter stringFromDate:(__bridge NSDate *)ABRecordCopyValue(person, kABPersonBirthdayProperty)];
[dateOfBirth setText:birthday];
Is there a fix around this and how important is it that I do fix it? I have one other potential leak of an object in my code.
A final note: I am using ARC.
You want this:
[lastName setText:(__bridge_transfer NSString *)ABRecordCopyValue(person, kABPersonLastNameProperty)];
The reason you're seeing the warning from the analyser is that ABRecordCopyValue returns a CFStringRef with +1 retain count. You're then casting to an NSString* but saying to ARC not to take ownership of the object. That means it won't automatically add in the release for you. So you need to tell ARC to take ownership during the cast into Objective-C object land which is done using __bridge_transfer.
You could also have done:
CFStringRef string = ABRecordCopyValue(person, kABPersonLastNameProperty);
[lastName setText:(__bridge NSString *)string];
CFRelease(string);
Since the functions are returning new objects (they have copy in the name) you need to release those objects somehow.
This can be done by calling the appropriate method to release it, or by using __bridge_transfer instead of __bridge, which instructs ARC to take over the memory management and release it when needed.
The mysteries of Objective-C plague me yet again.
I have a string. It's defined in a header file called "Common.h".
If I give it a value thusly:
_DATESTRING = #"2011-08-16";
There is no problem, and it sticks around forever, however, if I do this:
_DATESTRING = [format stringFromDate:[NSDATE dateWithTimeIntervalSinceNow:0]];
I get a "message sent to deallocated instance" further down the pipes.
Why?
// This is a string that's not going to be released
_DATESTRING = #"2011-08-16";
// This is a string that's autoreleased
_DATESTRING = [format stringFromDate:[NSDATE dateWithTimeIntervalSinceNow:0]];
// You want somethhing like this
_DATESTRING = [[format stringFromDate:[NSDATE dateWithTimeIntervalSinceNow:0]] retain];
In short, if your method name contains alloc, copy, new or mutableCopy you have to release it yourself. Otherwise it's already autoreleased so if you want to keep it around you need to retain it.
Where exactly is down the pipes?
The method stringFromDate: returns an autorelease object, so I'm quite sure that it's getting automatically deallocated when you want to use it. It doesn't happens with string literals because these do not follow the standard memory management conventions for objects.
You may want to add a retain message:
_DATESTRING = [[format stringFromDate:
[NSDATE dateWithTimeIntervalSinceNow:0]] retain];
because -stringFromDate: returns autoreleased object. If you want it to stick around forever, you need to send -retain message to it, that is:
_DATESTRING = [[format stringFromDate:[NSDATE dateWithTimeIntervalSinceNow:0]] retain];
I have Question related to nsdate declaration.
NSDate *sortDate;
#property(nonatomic,retain) NSDate *sortDate;
#synthesize sortDate;
sortDate=[NSDate date];
I assign NSdate field in my class with above Procedure.I successfully assign value to my NSDATE(sortarray).Whaen when i retrieve its value's App craches with this message.
"malloc double free/non- aligned pointer being freed set a breakpoint in malloc_error_break to debug"
Give excess bad error.Some time it show,
When i remove NSDATE field from my class.App Run successfully.
Any thing wrong regarding declaration?
Any Solution.
Thanks in advance.
The date instance you get is autoreleased and not owned by you. If you assign directly to the ivar you have to take ownership, e.g.:
sortDate = [[NSDate date] retain];
It's usually better though to use the declared property, which takes care of that for you:
self.sortDate = [NSDate date];
Don't forget to relinquish ownership on dealloc, e.g.:
self.sortDate = nil;
See the Cocoa memory management rules and the declared properties documentation.
Can anyone see potential leaks in this code? I'm getting a "100%" leak according to Instruments on the line "NSString *ender = [temp stringFromDate:now];"
NSDateFormatter* temp = [[NSDateFormatter alloc] init];
[temp setDateFormat:#"yyyy-MM-dd"];
NSDate *now = [NSDate date];
NSString *ender = [temp stringFromDate:now];
DashboardViewController *controller = [[DashboardViewController alloc] init];
[controller initWithStartDate:ender andEndDate:ender];
[controller initAccount:account];
[self presentModalViewController:controller animated:NO];
[temp release];
Do you release controller after all that stuff?
This advice is unrelated to original question, but I think you should rename the initWithStartDate:andEndDate: and initAccount: methods since typically methods with "init" in the name return new instances.
Perhaps create your own -(id)initWithStartDate:endDate:account: and call the designated initializer from within.
Then you would create a new controller instance with
DashboardViewController *controller = [[DashboardViewController alloc] initWithStartDate:ender endDate:ender account:account];
Gonzalo
Since you pass your controller instance to the -presentModalViewController: method, that method will retain your controller. So you can safely release your controller, but you also should release your controller, since the memory management rules state that objects that you alloc+inited are owned by you and must be released.
On the other hand - just a small note - NSDateFormatter is a "heavy" object, cache the instance and reuse it, if it's possible. Probably this is also the reason why Apple deprecated this method. You might call -init on NSDateFormatter from iOS 2.0 till iOS 3.2, but it is deprecated after iOS 3.2 .
I try to get the last modification date of a file:
NSFileManager *fm = [[NSFileManager alloc] init];
NSError *err;
NSDate *lastModif = [[fm attributesOfItemAtPath:filename error:&err] objectForKey:NSFileModificationDate];//filename is ok ;-)
if(err == nil) {
[lastModif retain];
//I can put a NSLog of lastModif here, it works !!
NSTimeInterval lastModifDiff = [lastModif timeIntervalSinceNow];//crash here
}
I don't understand why the NSDate seems to be released, why the retain does not retain it.
Thank you if you have any idea...
You don't need to retain lastModif. I think you might be trying to treat lastModifDiff as an object of some sort when you do an NSLog with it or whatever you do with it afterwards. NSTimeInterval is a typedef to a double so you need to treat it as a double or [NSNumber numberWithDouble:lastModifDiff] if you want to use it like an object.
I'm having the same problem, but this post seemed germane:
NSDate : timeIntervalSinceNow crash
I'm writing a simple set of functions- startClock/endClock -using NSDate to determine FPS in my game loop. Except that timeIntervalSinceNow crashes, claiming that my earlier set NSDate object doesn't exist.
I know for a fact that the NSDate object has a retain count of 1 when I call startClock, but my theory is that NSDate instances are internally rigged to auto-release when they get bored and aren't feeling useful.
Using retain/release to assume ownership of these flighty and ephemeral NSDate objects worked for me.