Leaking memory with Cocoa garbage collection

Question

I've been beating my head against a wall trying to figure out how I had a memory leak in a garbage collected Cocoa app. (The memory usage in Activity Monitor would just grow and grow, and running the app using the GC Monitor instruments would also show an ever-growing graph.)

I eventually narrowed it down to a single pattern in my code. Data was being loaded into an NSData and then parsed by a C library (the data's bytes and length were passed into it). The C library has callbacks which would fire and return sub-string starting pointers and lengths (to avoid internal copying). However, for my purposes, I needed to turn them into NSStrings and keep them around awhile. I did this by using NSString's initWithBytes:length:encoding: method. I assumed that would copy the bytes and NSString would manage it appropriately, but something is going wrong because this leaks like crazy.

This code will "leak" or somehow trick the garbage collector:

- (void)meh
{
    NSData *data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"holmes" ofType:@"txt"]];
    const int substrLength = 80;

    for (const char *substr = [data bytes]; substr-(const char *)[data bytes] < [data length]; substr += substrLength) {
        NSString *cocoaString = [[NSString alloc] initWithBytes:substr length:substrLength encoding:NSUTF8StringEncoding];
        [cocoaString length];
    }
}

I can put this in timer and just watch memory usage go up and up with Activity Monitor as well as with the GC Monitor instrument. (holmes.txt is 594KB)

This isn't the best code in the world, but it shows the problem. (I'm running 10.6, the project is targeted for 10.5 - if that matters). I read over the garbage collection docs and noticed a number of possible pitfalls, but I don't think I'm doing anything obviously against the rules here. Doesn't hurt to ask, though. Thanks!

Project zip

Here's a pic of the object graph just growing and growing:

Answer 1

This is an unfortunate edge case. Please file a bug (http://bugreport.apple.com/) and attach your excellent minimal example.

The problem is two fold;

• The main event loop isn't running and, thus, the collector isn't triggered via MEL activity. This leaves the collector doing its normal background only threshold based collections.

• The data stores the data read from the file into a malloc'd buffer that is allocated from the malloc zone. Thus, the GC accounted allocation -- the NSData object itself -- is really tiny, but points to something really large (the malloc allocation). The end result is that the collector's threshold isn't hit and it doesn't collect. Obviously, improving this behavior is desired, but it is a hard problem.

This is a very easy bug to reproduce in a micro-benchmark or in isolation. In practice, there is typically enough going on that this problem won't happen. However, there may be certain cases where it does become problematic.

Change your code to this and the collector will collect the data objects. Note that you shouldn't use collectExhaustively often -- it does eat CPU.

- (void)meh
{
    NSData *data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"holmes" ofType:@"txt"]];
    const int substrLength = 80;

    for (const char *substr = [data bytes]; substr-(const char *)[data bytes] < [data length]; substr += substrLength) {
        NSString *cocoaString = [[NSString alloc] initWithBytes:substr length:substrLength encoding:NSUTF8StringEncoding];
        [cocoaString length];
    }
    [data self];
    [[NSGarbageCollector defaultCollector] collectExhaustively];
}

The [data self] keeps the data object alive after the last reference to it.

Answer 2

Hi,

I have a very similar problem, but unfortunately this fix doesn't help in my case. Below is a function from our open source library Integrating Vision Toolkit (IVT, ivt.sourceforge.net), which updates the contents of an image widget. This was working perfectly without leaking until Mac OS X 10.5:

void CocoaSetImage(void *ptr, int width, int height, unsigned char *pixels)
{
 id widget = (id) ptr;

 NSImage *nsimage = [widget image];
 NSBitmapImageRep *bmp = (NSBitmapImageRep *) [[nsimage representations] objectAtIndex: 0];

 unsigned char *bytes = [bmp bitmapData];

 if (bytes)
  memcpy(bytes, pixels, width*height * 3);

 [widget setNeedsDisplay: YES];
}

With Mac OS X 10.6 this piece of code produces gigabytes of memory leakage within few seconds. I tried to place the collectExhaustively call basically everywhere, but it doesn't help. What else can I do? If I don't call this function for updating the image widget contents, leakage will not happen. Users report the same problem with updating other widget elements (but in those cases leakage is not as severe as here, due to the significantly less amount of memory involved).

Any help or hints are very welcome. This is somewhat urgent, since our users suddenly experience a huge memory leak simply by updating to Snow Leopard, which makes any IVT GUI application crash at some point, since it runs out of memory. Interestingly, in my case, memory usage converges to approx. 1.7 GB (which is still very problematic).

Kind regards, Pedram

enter code here