0

My app is crashing due to an over-released object and I have narrowed it down to the early call of dealloc in a custom class. This causes a crash attributed to an NSMutableArray that is using the custom class listed below:

#import <Foundation/Foundation.h>

@interface GraphData : NSObject{
    NSInteger key;
    NSString *value;
}

@property (nonatomic, readwrite) NSInteger key;
@property (nonatomic, retain) NSString *value;

-(id)initWithPrimaryKey:(NSInteger) xid;
-(id)initWithName:(NSString *)n key:(NSInteger)i;

@end


#import "GraphData.h"

@implementation GraphData

@synthesize  key,value;

-(id)initWithPrimaryKey:(NSInteger) xid{
    //[super init];
    self=[super init];
    if (self){
    self.key = xid;
    self.value = @"";
    }
    return self;

}
-(id)initWithName:(NSString *)n key:(NSInteger)i{
    self=[super init];
    if (self){
    self.key = 0;
    self.value = n;
    }
    return self;

}
-(void)dealloc{
    NSLog(@"Say bye to %@, kids!", self);
    [value release], value = nil;
    [super dealloc];

}

@end

Weirdly I'm using GraphData in another class and it works without a problem. In this case however the dealloc calls just before I synthesise the NSMutableArray theNewData property; but after I have synthesised it three times.

-(NSMutableArray*)fillDataInArray:(NSInteger)keyphrase_id{
    NSLog(@"lsd");
    NSLog(@"Keyphrase_id:%d", keyphrase_id);

    NSDate *startdate = [self getDateForApplicationInstalled];
    NSDate *enddate = [NSDate date];

    NSString *dateString1=[[NSString alloc] initWithString: [fmt stringFromDate:startdate]];
    NSString *dateString2=[[NSString alloc] initWithString: [fmt stringFromDate:enddate]];

    NSMutableArray *newDataNew = [[NSMutableArray alloc]init];
    self.theNewData = newDataNew;
    [newDataNew release];


    selStmt = nil;


    // build select statement
    if (!selStmt)
    {
        const char *sql = "select distinct position, key_time from ranking where keyphrase_id = ? and key_time between ? and ? order by key_time";


        if (sqlite3_prepare_v2(database, sql, -1, &selStmt, NULL) != SQLITE_OK)
        {
            selStmt = nil;
        }

        NSInteger n = keyphrase_id;
        sqlite3_bind_int(selStmt, 1, n);

        sqlite3_bind_text(selStmt, 2, [dateString1 UTF8String] , -1, SQLITE_TRANSIENT);
        sqlite3_bind_text(selStmt, 3, [dateString2 UTF8String] , -1, SQLITE_TRANSIENT);

        NSLog(@"SQL query is: [%s]", sql);
    }
    if (!selStmt)
    {
        NSAssert1(0, @"Can't build SQL to read keyphrases [%s]", sqlite3_errmsg(database));
    }

    int ret;

    while ((ret=sqlite3_step(selStmt))==SQLITE_ROW) 
    { 
        GraphData *item = [[GraphData alloc]init];

        item.key = sqlite3_column_int(selStmt, 0);
        item.value = [NSString stringWithUTF8String:(char *)sqlite3_column_text(selStmt,1)];

        [self.theNewData addObject:item]; 

        [item release];
    }

    sqlite3_reset(selStmt); // reset (unbind) statement

    [dateString2 release];
    [dateString1 release];

    return theNewData;

}

It's also accessed in a different method:

-(NSMutableArray *) getDataForCharts:(int)seriesIndex{
    NSLog(@"speed");

    NSDate *startdate = [self getDateForApplicationInstalled];
    NSDate *enddate = [NSDate date];


    NSString *dateString1=[[NSString alloc] initWithString: [fmt stringFromDate:startdate]];
    NSString *dateString2=[[NSString alloc] initWithString: [fmt stringFromDate:enddate]];


    NSMutableArray *newDataNew = [[NSMutableArray alloc]init];
    self.actionNoteData = newDataNew;
    [newDataNew release];


    selStmt = nil;


    // build select statement
    if (!selStmt)
    {

        const char *sql = "";



        if (seriesIndex == 4) sql = "select distinct 105 score, notes_date from notes where iscompleted =1 and domain_id = ? and notes_date between ? and ? order by notes_date";

        if (sqlite3_prepare_v2(database, sql, -1, &selStmt, NULL) != SQLITE_OK)
        {
            selStmt = nil;
        }


        NSInteger n = domain_id;
        sqlite3_bind_int(selStmt, 1, n);

        sqlite3_bind_text(selStmt, 2, [dateString1 UTF8String] , -1, SQLITE_TRANSIENT);
        sqlite3_bind_text(selStmt, 3, [dateString2 UTF8String] , -1, SQLITE_TRANSIENT);

        NSLog(@"SQL query is: [%s]", sql);
    }
    if (!selStmt)
    {
        NSAssert1(0, @"Can't build SQL to read keyphrases [%s]", sqlite3_errmsg(database));
    }

    // loop reading items from list
    int ret;

    while ((ret=sqlite3_step(selStmt))==SQLITE_ROW) 
    { 
        GraphData *item = [[GraphData alloc]init]; // create item

        item.key = sqlite3_column_int(selStmt, 0);
        item.value = [NSString stringWithUTF8String:(char *)sqlite3_column_text(selStmt,1)];

        NSLog(@"Key:%d", sqlite3_column_int(selStmt, 0));
        NSLog(@"Value:%s", sqlite3_column_text(selStmt,1));

        [self.actionNoteData addObject:item]; // add to list
        [item release]; // free item

    }


    sqlite3_reset(selStmt); // reset (unbind) statement

    [dateString2 release];
    [dateString1 release];
    return actionNoteData;

}

Zombie points to [i release]; but this is the exact statement called earlier which doesn't result in a crash.

if (index == 4) {
        dateComponents.day = ([dateComponents day] -1 ) + dataindex + 1;

        if (dataForPlotActionNote.count > dataindex) {

            if ([dataForPlotActionNote objectAtIndex:dataindex]) {
                GraphData *i = (GraphData *) [dataForPlotActionNote objectAtIndex:dataindex];
                NSDate *date = [[[NSDate alloc] init] autorelease]; 

                date =[fmt dateFromString:i.value];

                datapoint.xValue = date;//[cal dateFromComponents:dateComponents];
                datapoint.yValue = [NSNumber numberWithDouble:(i.key)];

                [i release];
            }
        }
    }

What could cause the dealloc call to occur halfway through the executing code?

Could making a GraphData property and reseting it each time help keep it alive long enough?

Jace
  • 145
  • 2
  • 11
  • How are you declaring the value property? – Johan Kool Jun 15 '12 at 14:37
  • 1
    The interesting code is probably wherever you are declaring, creating, and retaining the GraphData objects. – Phillip Mills Jun 15 '12 at 14:39
  • Edited above question with additional code. – Jace Jun 15 '12 at 15:01
  • Please show the @interface code where these properties are declared. – Chris Trahey Jun 15 '12 at 15:06
  • The next step along this path would be looking at the state of the owning array when your object is dealloc'd (or break in the dealloc and look at the stack trace) but, rather than speculate on which things are being over-released, you might want to try running under Instruments with zombie detection. – Phillip Mills Jun 15 '12 at 15:11
  • offtopic: don't use dot notation in init and dealloc methods: http://stackoverflow.com/a/5932733/644629 and http://stackoverflow.com/a/9086811/644629 – CarlJ Jun 15 '12 at 15:11
  • I've done the zombie detection, it highlights a release of GraphData after I have allocated it in the same way I did previously for the 3 other instances of it. This is what confuses me so greatly. More code added. – Jace Jun 15 '12 at 15:15

1 Answers1

0

The [i release] problem makes sense. When you get a reference to the object that's inside dataForPlotActionNote you don't increase its retain count, so you shouldn't be reducing the count either.

The places where you use [item release] are different in that you've created those objects with alloc and therefore do have them retained.

Phillip Mills
  • 30,888
  • 4
  • 42
  • 57
  • Yes this makes sense. When adding the items GraphData is allocated; when referencing them later however it isn't. It's odd though since the other arrays are referenced in the exact same way and the over released object only occurs for dataForPlotActionNote. I'll fiddle around with it and see what I can rearrange. – Jace Jun 18 '12 at 11:01
  • A few changes and it's working perfectly with no leaks. Thanks for looking at my question and pointing this out to me. This is a great example of the potential pitfalls one might come across when inheriting a project for the last month of development. – Jace Jun 18 '12 at 11:06
  • As an aside, the "Product->Analyze" command is often able to point out things like this. – Phillip Mills Jun 18 '12 at 11:09