I've created a small class that loads dictionary items from a plist file. The getSettingForKey method works the first time I call the static method, however after a few more calls the dictionary throws a SIGABRT exception for a call with the same key that worked on a previous call. Any ideas?
static NSDictionary *dictionary = nil;
static NSLock *dictionaryLock;
#implementation ApplicationSettingsHelper
+ (void) initialize
{
dictionaryLock = [[NSLock alloc] init];
// Read plist from application bundle.
NSString *path = [[NSBundle mainBundle] bundlePath];
NSString *finalPath = [path stringByAppendingPathComponent:#"Xxxx.plist"];
dictionary = [NSDictionary dictionaryWithContentsOfFile:finalPath];
// dump the contents of the dictionary to the console.
for(id key in dictionary)
{
NSLog(#"bundle: key=%#, value=%#", key, [dictionary objectForKey:key]);
}
}
+ (NSDictionary *)dictionaryItems
{
[dictionaryLock lock];
if (dictionary == nil)
{
[self initialize];
}
[dictionaryLock unlock];
return dictionary;
}
+(id)getSettingForKey:(NSString *)key
{
return [[self dictionaryItems] objectForKey:key];
}
#end
Moshe - I've taken your suggestion and updated to use NSUserDefaults instead:
+ (void)load
{
// Load the default values for the user defaults
NSString* pathToUserDefaultsValues = [[NSBundle mainBundle]
pathForResource:#"Xxxx"
ofType:#"plist"];
NSDictionary* userDefaultsValues = [NSDictionary dictionaryWithContentsOfFile:pathToUserDefaultsValues];
// Set them in the standard user defaults
[[NSUserDefaults standardUserDefaults] registerDefaults:userDefaultsValues];
}
+ (id)getSettingForKey:(NSString *)key
{
return [[NSUserDefaults standardUserDefaults] valueForKey:key];
}
Your dictionary has probably been deallocated, causing an invalid memory access. When you create a dictionary using the dictionaryWithContentsOfFile: method, it is autoreleased, which means it will automatically be released in the future. Since you never retain the dictionary, that release will cause the dictionary to be deallocated.
Also, most of your dictionaryItems method is useless.
[dictionaryLock lock];
if (dictionary == nil) {
[self initialize];
}
[dictionaryLock unlock];
The +initialize method is automatically called by the runtime before any other method is called on your class, unless you have a +load method. Since the runtime will call it for you and it will attempt to create the dictionary, the dictionary can only be nil in the dictionaryItems method if there wasn't enough memory to create it, in which case it will fail again. Also, if you don't use the lock anywhere else, it is unnecessary also, since removing that check would cause it to be locked and immediately unlocked. Therefore, you can remove the lock and change your dictionaryItems method to simply:
+ (NSDictionary *)dictionaryItems {
return dictionary;
}
In addition to #ughoavgfhw's answer, you are also initializing dictionaryLock after you are locking it. Unless you are initializing dictionaryLock somewhere else, I'm surprised your code is getting as far as it is.
Edit: I see from #ughoavgfhw's edit that +initialize is called before anything else, so your lock is initialized there.
Related
UIImage API Reference Document:-
initWithContentsOfFile:
Initializes and returns the image object with the contents of the specified file.
- (id)initWithContentsOfFile:(NSString *)path
Parameters
path
The path to the file. This path should include the filename extension that identifies the type of the image data.
Return Value
An initialized UIImage object, or nil if the method could not find the file or initialize the image from its contents.
Considering this scenario, suppose I have a class, it could be extension of any class. Just took UIImage for example.
#interface myImage : UIImage
{
BOOL isDefaultSet;
}
-(id)initWithDefaultImage;
#end
#implementation myImage
-(id)initWithDefaultImage
{
NSString *path = [[NSBundle mainBundle] pathForResource:#"someInvalidImage" ofType:#"png"];
idDefaultSet = YES;
return [self initWithContentsOfFile:path];
}
#end
//somewhere in other class:
NSString *path = [[NSBundle mainBundle] pathForResource:#"someInvalidImage" ofType:#"png"];
myImage *myObject = [[myImage alloc] initWithDefaultImage];
UIImage *yourObject = [[UIImage alloc] initWithContentsOfFile:path];
now here in both cases,
"alloc" gives "retainCount+1"
and if
initWithDefaultImage/initWithContentsOfFile
returned nil due to some issue - lets say (invalid file path), this memory will be leaked as
myObject/yourObject
will be set to nil even though the allocation was made before init.
I have seen many implementations for extended classes/interfaces in this manner. I'm confused how memory is being handled here? can anyone share view on this?
if [super init] returns nil, nil is returned. so the control returns from method and if (someInitializingFailed) block will never be executed and memory will be leaked as alloc is already executed before calling "initWithFoo"
if [super init] returns nil, super's init has already cleaned after itself and released the memory allocated by alloc.
From Handling Initialization Failure:
You should call the release method on self only at the point of failure. If you get nil back from an invocation of the superclass’s initializer, you should not also call release.
Usually the corresponding initializer releases self (the new object) before returning nil, as in:
- (id)initWithFoo
{
self = [super init];
if (!self) return nil;
if (someInitializingFailed) {
[self release];
return nil;
}
return self;
}
You can assume that -[UIImage initWithContentsOfFile:] is implementing the same pattern. So unless Instruments does tell you there's a leak you don't need to do any special handling in your case.
You are right, sometimes people forget to handle this leak. The allocated memory needs to be released if we cannot proceed with the initialisation.
-(id)initWithDefaultImage
{
NSString *path = [[NSBundle mainBundle] pathForResource:#"someInvalidImage" ofType:#"png"];
if (path != nil)
{
self = [super initWithContentsOfFile:path];
}
else // cannot proceed with init
{
[self release];
self = nil;
}
return self;
}
I have a model class that keeps track record being built by multiple views. It has a NSMutableDictionary that has the fields and values I eventually write to the database. It is saved to a plist and loaded back when needed. I thought that I was keeping track of my memory, but it throws a EXC_BAD_ACCESS when I try to release the Dictionary. Here is my interface:
#import <Foundation/Foundation.h>
#interface CurrentEntryModel : NSObject {
NSMutableDictionary *currentEntry;
}
#property (nonatomic, retain) NSMutableDictionary *currentEntry;
- (void) setValue: (NSString *)value;
- (NSString *) getValue;
#end
My understanding is that currentEntry should be retained and I would have to release it during dealloc.
Here is my implementation (this isn't the entire class just the relevant parts):
#import "CurrentEntryModel.h"
#implementation CurrentEntryModel
#synthesize currentEntry;
-(id) init {
if ( self = [super init] )
{
//check for file
NSFileManager *fileManager = [NSFileManager defaultManager];
NSString *file;
file = #"location.plist";
if ([fileManager fileExistsAtPath:file]){
NSLog(#"file exists");
currentEntry = [[NSMutableDictionary alloc] initWithContentsOfFile:file];
}else {
NSLog(#"file doesn't exist");
currentEntry = [[NSMutableDictionary alloc ] initWithCapacity:1];
NSDate *testDate = [NSDate date];
[currentEntry setObject:testDate forKey:#"created"];
[currentEntry writeToFile:file atomically:YES];
}
}
return self;
}
- (void) setValue: (NSString *)value {
[currentEntry setObject:value forKey:#"location"];
}
- (NSString *) getValue {
return [currentEntry objectForKey:#"location"];
}
- (void) dealloc{
[currentEntry release];
[super dealloc];
}
#end
If I init this class it will automatically create the dictionary and if I call one of the set or get methods it seems like the dictionary is retained as it will dealloc correctly. If the class is just initialized and then no methods are called it will throw the EXC_BAD_ACCESS errors. If I am not mistaken when the file doesn't exist I don't initialize the dictionary correctly because the method starts with dictionary and not init. Although every time I run this the file is there so it always uses the the file found logic and I thought that that will retain the variable.
Am I not initializing the dictionary correctly?
Edit - changed the code on the convenience method to reflect the proper way. Everyone take note of what Squeegy has to say.
This is bad bad bad.
else {
NSLog(#"file doesn't exist");
currentEntry = [[NSMutableDictionary alloc ] dictionaryWithCapacity:1];
dictionaryWithCapacity: is a class method on NSMutableDictionary which returns an autoreleased object, and you don't retain it. So the run loop ends, and the dictionary gets autoreleased. Then you run [currentEntry release] in your dealloc and it explodes because that object is deallocated already.
you probably wan't initWithCapacity: instead. Always pair alloc with a method that starts with init.
Also, when using retained properties like this, I usually let the property figure this out for me, and only work with autoreleased objects. You just have to remember less rules, and there are less gotchas.
- (id)init {
// ...
self.currentEntry = [NSMutableDictionary dictionWithContentsOfFile:file];
// ...
}
- (void)dealloc {
//...
self.currentEntry = nil;
//...
}
This way you never have to call retain or release directly on the object. In my experience, this results in less confusing bugs. But it's also point of style among many ObjC programmer that not everyone agrees with.
Joshua -
+ (id)dictionaryWithCapacity:(NSUInteger)numItems
is a class method of NSDictionary. So when you call it, it should be:
[NSMutableDictionary dictionaryWithCapacity:1];
Not:
[[NSMutableDictionary alloc] dictionaryWithCapacity:1];
Further, [NSMutableDictionary dictionaryWithCapacity:] returns an autoreleased object. If you want to keep the dictionary as an ivar and not have it autoreleased on the next cycle of the run loop, you should call:
[currentEntry retain];
So, basically, change it to:
currentEntry = [[NSMutableDictionary alloc] initWithCapacity:1];
or:
currentEntry = [[NSMutableDictionary dictionaryWithCapacity:1] retain];
The first one probably makes more sense, since the connivence class methods were designed to be used when you wanted an autoreleased instance.
I was running Leaks tool and discovered a massive leak in my Dictionary mutableDeepCopy but I can't figure out what's wrong with the code. Any suggestions?
#interface RootViewController : UIViewController{
NSDictionary *immutableDictionary;
NSMutableDictionary *mutableDictionary;
}
Here is the line of code that's highlighted in Instruments
self.mutableDictionary = [self.immutableDictionary mutableDeepCopy];
Here is the method for creating a mutable copy of a Dictionary
#interface NSDictionary(MutableDeepCopy)
-(NSMutableDictionary *)mutableDeepCopy;
#end
Here is method implementation, I've highlighted the code that Leaks saids is leaking 100%
- (NSMutableDictionary *) mutableDeepCopy {
NSMutableDictionary *dictionaryToReturn = [NSMutableDictionary dictionaryWithCapacity:[self count]];
NSArray *keys = [self allKeys];
for(id key in keys) {
id value = [self valueForKey:key];
id copy = nil;
if ([value respondsToSelector:#selector(mutableDeepCopy)]) {
copy = [value mutableDeepCopy];
} else if ([value respondsToSelector:#selector(mutableCopy)]) {
copy = [value mutableCopy]; //This is the Leak
}
if (copy == nil) {
copy = [value copy];
}
[dictionaryToReturn setValue:copy forKey:key];
}
return dictionaryToReturn;
}
You need to analyse this in light of Apple's Memory Management Rules.
Starting with this line:
self.mutableDictionary = [self.immutableDictionary mutableDeepCopy];
I would expect mutableDeepCopy to return an object I own, so at some point I need to release or autorelease it. e.g.
NSMutableDeepCopy* temp = [self.immutableDictionary mutableDeepCopy];
self.mutableDictionary = temp;
[temp release];
or
self.mutableDictionary = [[self.immutableDictionary mutableDeepCopy] autorelease];
So now we need to look at mutableDeepCopy. Because it has 'copy' in the name it needs to returned an "owned" object which, in practice means "forgetting" to release the returned object. You have already failed to do that when you create the returned object in the first line, since dictionaryWithCapacity: gives you an object you do not own. Replace it with
NSMutableDictionary *dictionaryToReturn = [[NSMutableDictionary alloc] initWithCapacity:[self count]];
Now you own it.
It is important that you make your mutableDeepCopy obey the rules because it means you can treat the objects returned from mutableDeepCopy, mutableCopy and copy in exactly the same way. In all three cases you own the object copy that you insert into the array. Because you own it, you must release it or it'll leak as you found out. So, at the end of the loop, you need
[copy release];
That'll stop the leak.
How is your property declared? If is is retain or copy, then this doesn't leak.
Your problem is that the name mutableDeepCopy suggests that it returns a retained object, and not an autoreleased one as it actually does.
Edit:
And at the mutableDeepCopy itself, you need to release the copy variable after adding to the dictionary.
mutableCopy increments the retain count of the object, as does setValue:forKey:. This means that when dictionaryToReturn is dealloc'ed, the object that had mutableCopy called still has a retain count of one.
Try doing this instead:
copy = [[value mutableCopy] autorelease];
Everything is working fine until I call the saveFile method (shown below) to write the file back to disk, where it crashes. What am I doing wrong?
This is part of my viewDidLoad method where I open the file, which works fine.
//Get The Path
[self initPath];
dictionary = [[NSMutableDictionary alloc] initWithContentsOfFile:accountsFilePath];
if (accountsArray == nil) {
accountsArray = [[[NSMutableArray alloc]init] autorelease];
}
if (countArray == nil) {
countArray = [[[NSMutableArray alloc]init] autorelease];
}
countArray = [dictionary objectForKey:#"count"];
accountsArray = [dictionary objectForKey:#"username"];
Then I load it into a tableview. I then add some new items to it, which works fine. Then I call this method to save it and it crashes:
-(void)saveFile {
[dictionary setObject:accountsArray forKey:#"username"];
[dictionary setObject:countArray forKey:#"count"];
[dictionary writeToFile:accountsFilePath atomically:YES];
}
You are autoreleasing countArray and accountsArray just after initializing them. Thet may well be already released when you try to save them. Try commenting the autorelease for both of them (and remember to release them somewhere, maybe in the dealloc method).
// what if the path is not found, file is not load and in turn dictionary is nil
dictionary = [[NSMutableDictionary alloc] initWithContentsOfFile:accountsFilePath];
// first time you create accountsArray, countArray
if (accountsArray == nil) {
accountsArray = [[[NSMutableArray alloc]init] autorelease]; }
if (countArray == nil) {
countArray = [[[NSMutableArray alloc]init] autorelease]; }
// hey why you assign accountsArray to a new one again, what about the old one you just init?
// if dictionary is nil, countarray will be nil too
countArray = [dictionary objectForKey:#"count"];
accountsArray = [dictionary objectForKey:#"username"];
////
////
////////////////////////////////////////////////////////////////
what is your crash message?
what is your accountsFilePath
can you read the dictionary file?
one thing you may want to know
writeToFile will not create a new folder for you
so all folder in accountsFilePath is a must to be exist.
otherwise you may want to create that folder using nsfilemanager
Are all your variables in scope? I assume accountsFilePath and dictionary are class variables? If not they might die at the end of viewDidLoad.
The other thing that might bite you is the capacity of your dictionary is too small, or that the iPhone doesn't like you using the setObject method to overwrite key/value pairs like that. Perhaps try calling removeObjectForKey: and then add it back as you have above?
You probably already did this, but I would inspect dictionary and accountsFilePath in gdb or by using NSLog right before the writeToFile:atomically: call.
You also might want to share more surrounding code to show what else is going on with respect to this dictionary.
I've been using NSZombie with much success for debugging random crashes as well.
Hey folks - I'm writing a pretty simple iPhone application. The data comes from a plist file (NSDictionary basically), that I'm trying to load into a singleton class and use across my various view controllers to access the data.
Here's the implementation for my singleton (heavily modeled after this thread)
#implementation SearchData
#synthesize searchDict;
#synthesize searchArray;
- (id)init {
if (self = [super init]) {
NSString *path = [[NSBundle mainBundle] bundlePath];
NSString *finalPath = [path stringByAppendingPathComponent:#"searches.plist"];
searchDict = [NSDictionary dictionaryWithContentsOfFile:finalPath];
searchArray = [searchDict allKeys];
}
return self;
}
- (void)dealloc {
[searchDict release];
[searchArray release];
[super dealloc];
}
static SearchData *sharedSingleton = NULL;
+ (SearchData *)sharedSearchData {
#synchronized(self) {
if (sharedSingleton == NULL)
sharedSingleton = [[self alloc] init];
}
return(sharedSingleton);
}
#end
So whenever I try to access the searchDict or searchArray properties elsewhere in my application (like a TableView delegate) like so:
[[[SearchData sharedSearchData] searchArray] objectAtIndex:indexPath.row]
I get an exception stating *** -[NSCFSet objectAtIndex:]: unrecognized selector sent to instance 0x5551f0
I'm not really sure why the objectAtIndex message is being sent to an NSCFSet object, I feel like my singleton is implemented wrong or something. I also tried a more complex singleton implementation like the one recommended by apple in the aforementioned thread and had the same problem. Thanks for any insight you can provide.
In your -init method you are directly accessing your instance variables and you are not retaining them. They're getting deallocated and their memory is being used up by other objects later on in your application's lifetime.
Either retain your objects that you're creating there or use the non-convenience methods to generate them.
searchDict = [[NSDictionary alloc] initWithContentsOfFile:finalPath];
searchArray = [[searchDict allKeys] retain];
Whenever you assign synthesized variables, do it through 'self', so:
- (id)init {
if (self = [super init]) {
NSString *path = [[NSBundle mainBundle] bundlePath];
NSString *finalPath = [path stringByAppendingPathComponent:#"searches.plist"];
self.searchDict = [NSDictionary dictionaryWithContentsOfFile:finalPath];
self.searchArray = [searchDict allKeys];
}
return self;
}
Also make sure you've set up those variables to be 'retain'ed in the header file.
Hi, Can you tell me what is the advantage, when we assign synthesized variables through 'self'? Thank you shiva
the values are set through the setter; it releases the previous value and retains the one you assign.