As a follow-up, I got a chance to run my posted code under Instruments on 10.6.2, and I don't see any of the OP's originally reported problems. There is no unexpected memory consumption, and no leaks.
The conditions of the test runs were as follows.
First, I generated a 50k-line data file as input:
The exprs.txt file contained 3 expressions, so there will be a total of 3 iterations of main()'s loop. This was borne out by observation.
Next, I compiled the .m file for i386 and x86_64. This made no difference to the test runs. There was similar memory usage in both cases.
In Instruments.app I choose the Leaks template, which includes object alloc information and leak detection. No leaks were ever detected in any test run.
When I ran the program, the memory consumption plainly increases at each of the 3 iterations of the loop. This is exactly as expected.
The increase corresponds to the call to grepFileForExpression(), which greps the entire file and collects results by reading and parsing a single NSString. There are a large number of NSStrings, and a moderate number of NSArrays during this time. The NSStrings occupy the largest amount of memory, by far. This is exactly as expected, given the algorithm.
Memory usage then drops down to approximately its starting value, which would correspond to the draining of the pool in the loop.
When the loop ends, there is very little memory still allocated, and none that can be pinpointed as belonging to NSTasks.
This situation doesn't change when the code is modified for a small input file (40 lines) and a large number of iterations (1000). The code changes to do this are as follows:
There is still the same cycle of memory consumption during the grepping, and subsequent cleanup that reduces memory consumption. The magnitude is less because the input file is smaller, but there are many more cycles, so any cumulative effects from NSTask would still show up. None were observed.
In conclusion, I don't see any problems.
I was unable to replicate the the OP's reported problem, because insufficient code was posted to run a test entirely from the OP's code.
Since I wrote some of the code I tested, it's possible that something I wrote differs from what the OP wrote, and that difference is the cause of the OP's observed problem. That's just a guess, because without code to run, there's no way to observe anything.
The conditions of the test runs were as follows.
First, I generated a 50k-line data file as input:
Code:
java -Dlines=50000 RanguvarGen abc.txtNext, I compiled the .m file for i386 and x86_64. This made no difference to the test runs. There was similar memory usage in both cases.
In Instruments.app I choose the Leaks template, which includes object alloc information and leak detection. No leaks were ever detected in any test run.
When I ran the program, the memory consumption plainly increases at each of the 3 iterations of the loop. This is exactly as expected.
The increase corresponds to the call to grepFileForExpression(), which greps the entire file and collects results by reading and parsing a single NSString. There are a large number of NSStrings, and a moderate number of NSArrays during this time. The NSStrings occupy the largest amount of memory, by far. This is exactly as expected, given the algorithm.
Memory usage then drops down to approximately its starting value, which would correspond to the draining of the pool in the loop.
When the loop ends, there is very little memory still allocated, and none that can be pinpointed as belonging to NSTasks.
This situation doesn't change when the code is modified for a small input file (40 lines) and a large number of iterations (1000). The code changes to do this are as follows:
Code:
#define MAX_ITER 1000
int main( int argc, const char * argv[] )
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSArray *values = exprsArray( @"./exprs.txt" ); // pathname may contain ~/
const int count = [values count];
// Choose larger of count or MAX_ITER
const int limit = (count < MAX_ITER) ? MAX_ITER : count;
NSLog( @"Starting %d iterations", limit );
for (int i = 0; i < limit; i++)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSArray *possibleMatches = grepFileForExpression([values objectAtIndex:i % count]);
NSLog( @" possible count: %d", [possibleMatches count] );
[pool drain];
}
...etc...There is still the same cycle of memory consumption during the grepping, and subsequent cleanup that reduces memory consumption. The magnitude is less because the input file is smaller, but there are many more cycles, so any cumulative effects from NSTask would still show up. None were observed.
In conclusion, I don't see any problems.
I was unable to replicate the the OP's reported problem, because insufficient code was posted to run a test entirely from the OP's code.
Since I wrote some of the code I tested, it's possible that something I wrote differs from what the OP wrote, and that difference is the cause of the OP's observed problem. That's just a guess, because without code to run, there's no way to observe anything.
() But have you set up break points at suspected code and tried that appraoch to find leaks?