Re: Memory Leak, part I
Re: Memory Leak, part I
- Subject: Re: Memory Leak, part I
- From: James Montgomerie <email@hidden>
- Date: Thu, 19 Feb 2009 09:41:37 +0000
Presuming th rest of your code is following the rules, I can't see
anything obviously wrong with this code leak-wise.
Do these leaks build up every time you run the code you pasted, or is
there just one in the app's lifetime? Can you post a full backtrace
for the leak? (It may be easier to copy-and-paste this from output
from the 'leaks' command-line took - just run 'leaks myapp' in the
Terminal). I vaguely remember that there may be spurious false-
positive leaks of small bits of memory like this when creating threads
(I can't find reference to it on the Internet though - maybe someone
else remembers this too and can comment?).
What you're doing with the thread's dictionary looks a little weird
(though I don't think it's the source of a leak, presuming that
itsCalcStatus behaves correctly regarding memory management) - you're
consulting the main thread's dictionary in startBgCalculation, but,
though you don't show the full code, you're presumably consulting the
newly created thread's dictionary inside the calls to itsCalcStatus
in shouldExit and endBgCalculation?
Note, by the way, that you wight want to put an autorelease pool
inside the loop in (3). If you don't, objects created within it and
autoreleased will not get the change to be fully released until the
loop finishes, which may be a problem depending on how many
autoreleased objects are created (this is certainly not a leak though
- they will get released when control returns to (2), it'll just mean
your app has a high peak memory requirement).
If you can't get to the bottom of this, a good approach would be to
create a test Xcode project and see how little code you can put in it
to re-create the problem; that would help us on the mailing list debug
the problem with you more than copy-and-pasted code, and I often find
that just thinking about it like this helps me when I'm trying to
debug a problem of my own. It'd also be valuable to include in a bug
report to Apple if it's not something you've done that's causing the
problem.
Jamie.
On 18 Feb 2009, at 23:09, John Love wrote:
[this is part I of a two-part plea for help]
I I have read Apple's "ManagingMemory.pdf" and am still having
difficulty understanding the use of MallocDebug which is detailed in
"MemoryMgmt.pdf". I have 5 methods in the generation of a
background thread and I cannot figure out where the memory leak is:
MallocDebug states that there is zero leakage for each of these
methods, but there is a leakage = 480 bytes in 24 nodes for
thread_start ????
(1)
- (void) startBgCalculation {
/*
setCalcStatus calls:
itsDictionary = [[NSThread currentThread]
threadDictionary];
[itsDictionary setValue:[NSNumber
numberWithInt:kCalculating] forKey:staticString#1];
*/
[self setCalcStatus:kCalculating];
[NSThread detachNewThreadSelector:@selector(bgCalcThread)
toTarget:self withObject:nil];
}
(2)
- (void) bgCalcThread {
NSAutoreleasePool *bgCalcThreadPool = [[NSAutoreleasePool
alloc] init];
[self doCalculation];
[self performSelectorOnMainThread:@selector(endBgCalculation/
*:*/)
withObject:nil
waitUntilDone:YES];
[bgCalcThreadPool release];
}
(3)
- (void) doCalculation {
for (row=1; row <= 10000; row++) { // many rows, therefore
much time
if ([self shouldExit]) break;
[self doCalculationForEachRow];
}
}
(4)
- (BOOL) shouldExit {
[self pingWorkbook]; // calls –setExcelError
(NSMutableDictionary, with 2nd key)
int NoExcelAppOrNoWorkbookErr = [self itsExcelError];
if (NoExcelAppOrNoWorkbookErr != kNoError) { // kNoError = 0
[self setCalcStatus:NoExcelAppOrNoWorkbookErr];
return YES;
}
CalcStatus theCalcStatus = [self itsCalcStatus]; //
(NSMutableDictionary, 1st key)
if (theCalcStatus == kStopped) { // = a 2nd int
return YES;
}
else {
return NO;
}
}
(5)
- (void) endBgCalculation/ {
CalcStatus theCalcStatus = [self itsCalcStatus]; //
(NSMutableDictionary, 1st key)
if (theCalcStatus == kCalculating) { // a 3rd int
// do stuff
}
else {
// do stuff
}
}
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden