iOS Mem leak using NSMutableArray?

Dirk the Daring said:

Code:

- (void) callingFunc;
	NSMutableArray *list = [[NSMutableArray alloc] init];
	[database getListNum:num ArrayOfNSIntegers:list];
	int val = [cards count];
	[list release];
}

Click to expand...

This isn't real code. It may be fragments of real code, but it won't compile.

You're missing the opening {, and you have a ; instead of {.

Is the blue-hilited variable-name an instance-variable? Or should it really be the list local variable?

I'm guessing because the green-hilited variable was cards in the original post.


When you post fake or fragmented code, you can't really expect anyone to comment on it when it contains such serious errors. There's no way for us to guess what's wrong in your real code by looking at damaged or mistyped code fragments. All we can see is what's wrong (or right) in whatever fragments you posted.

Whatever context there was in the real code has been completely eliminated in the posted and damaged fragments. It is entirely possible that in the process of "simplifying" what you posted, you have actually removed the leak.

If you expect a real answer to your question about a memory leak, we have to see the real code. Accuracy is important.

Dirk the Daring said:

Code:

// The number of rows in section #section. 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section 
{	
	NSMutableArray *trans = [[NSMutableArray alloc] init];
	[database [COLOR="Red"]GetTransactionsForCardID:[/COLOR]cardid ArrayOfNSIntegers:trans];
	int count = [trans count];
	[trans release];
	return count;
}

(database has the following method)

Code:

- (void) [COLOR="Blue"]GetCardsForStoreID:[/COLOR](int) storeid ArrayOfNSIntegers:(NSMutableArray *) array
{
	//NSLog(@"GetCardsForStoreID: id %d\n",storeid);
	
	// Clear the array.
	[array removeAllObjects];

	NSString *deletestore = [[NSString alloc] initWithFormat:@"SELECT id, storeid FROM CARDS WHERE storeid=%d ORDER BY id;",storeid];
	sqlite3_stmt *statement;
	if (sqlite3_prepare_v2(sqldata, [deletestore UTF8String], -1, &statement, nil)!=SQLITE_OK)
	{
		[deletestore release];
		NSLog(@"     Failed to get card list data\n");
		return;
	}
	
	while (sqlite3_step(statement)==SQLITE_ROW)
	{
		// Found another one.
		int cardid = sqlite3_column_int(statement,0);
		int cardstoreid = sqlite3_column_int(statement,1);
		
		if (cardstoreid == storeid)
		{
			// Match. add to array.
			NSNumber *num = [[NSNumber alloc] initWithInt:cardid];
			[array addObject:num];
			[num release];
		}
	}
	sqlite3_finalize(statement); // We're done.
	[deletestore release];
	return ;
}

Click to expand...

This still isn't right. The red-hilited name doesn't match the blue-hilited method name.

I see no obvious source of leaks in the GetCardsForStoreID method. Some perplexing things, yes, but no obvious leaks. There may well be an obvious leak in GetTransactionsForCardID, but since you haven't shown its code, AFAICT, all anyone can do is guess.

The first perplexing thing is why you'd pass an array, simply to clear it then fill it. As a design, it seems a lot clearer to me if it created an array, filled it, and returned it from GetCardsForStoreID. Passing by reference is an odd design choice here. If you were appending to an existing array, which might already contain other items, then passing the array to append to makes sense. As given, not so much.

Equally perplexing is that you don't seem to believe your database. The SELECT statement selects only rows where the 'storeid' column matches the value passed in. By nature, all other rows will be excluded. Yet you have an 'if' statement in the loop that checks whether the column value is identical to the passed-in value. That's redundant. Worse, if by some unfortunate circumstance you do happen to get a non-identical storeid value, it silently skips over all the erroneous data, as if everything was fine. Frankly, if you get results that are that far wrong, you probably have a damaged database, and the last thing you should do is silently ignore it. If storeid doesn't match, it should throw an exception or call abort() or immediately stop, rather than going on.

Dirk the Daring said:

#2: I chose to avoid returning an array out of frustration with the retain/release system-- Although I understand the concept of how it works, enough things happen behind the scenes that I'm not confident about having the correct reference count when I go to delete an object. (questions at end)

Click to expand...

If you're thinking about reference count, you're doing it wrong. Seriously. You should be thinking about ownership: Do I own this object at this point? If I don't own it, how do I claim ownership? If I do own it, what are my responsibilities at this point?

Read the Memory Management Guide, and memorize the basic rules of ownership.
http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html

Ownership is the fundamental principle behind memory management, and memory management is fundamental to every correctly working program. If you don't have a solid grasp of the fundamentals, then you're already beyond your skill level.

* Is there a way to print/view the current retain reference count of an object?

Click to expand...

There is, but it almost always leads you astray. Because reference count doesn't directly indicate your ownership. It could be someone else's ownership, and you believe things are fine when they're not.

* Is there a way to free memory regardless of the reference count?

Click to expand...

Why would you do that?

The reference count indicates the total of all ownership claims. If you free the object, you are revoking all ownership claims,, whether you know who the owners are or not, and whether you know what their ownership means or not.

Take care of your own claims of ownership, and let other's claims take care of themselves.

* Does the redundancy of the select/data check cause a problem? (The code will be changed regardless)

Click to expand...

Does any redundant code cause a problem?

It might. For one thing, it's redundant. For another, it's entirely redundant. And thirdly, it's completely redundant. If the needless verbosity and logical conditions embodied in the superfluous redundancy isn't an immediate problem, it could become one as the code changes over time. Redundant code must be maintained (all code is subject to bugs being introduced; the more code you have, the more places for bugs to be introduced). Immediate problems may include subtle bugs (typically in the scope of a redundant conditional block), inefficiency (unnecessary checks and conditionals), unecessary code size (redundant code is still code), and a general absence of clarity for those who read the code. Reading redundant code always makes me wonder whether the redundancy was intentional or whether it's actually a latent bug that's testing the wrong condition, and then what the correct condition might actually be.

If you want to code in failsafes, then use assertions. The C assert() function works, as does NSAssert. You can google them. If you don't know what assertions are and why you'd use them, there's a page for that:
http://en.wikipedia.org/wiki/Assertion_(computing)

chen8002004 said:

Is it necessary to release each item from the array?

Click to expand...

Read the "Memory Management Programming Guide". All of it.

There is a section under "Practical Memory Management", heading "Cases Which Often Cause Confusion", subheading "Using Collections".
http://developer.apple.com/library/...ical.html#//apple_ref/doc/uid/TP40004447-SW12