Use Instruments instead; it will be much easier to find your memory
leaks.
corbin
On Feb 18, 2009, at 3:09 PM, 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
On 19 Feb 2009, at 09:41, James Montgomerie wrote:
If you don't, objects created within it and autoreleased will not
get the change to be fully released until the loop finishes,
Not quite sure how I came up with sentence construction like that.
What I meant was, "If you don't, objects autor
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 t
[part II of my plea for help]
(3)
- (void) doCalculation {
for (row=1; row <= 1; row++) { // many rows, therefore
much time
if ([self shouldExit]) break;
// do calculation for each row
}
}
(4)
- (BOOL) shouldExit {
[self pingWorkbook]; /
[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 mem
