nodeForXPath leaks memory

  • I posted this on usenet, but still could not solve the problem. Maybe
    someone here can help me:

    I have a subclass of NSXMLDocument that I use as an XMLParser. While
    running my program through MallocDebug and Leaks, I see that I am
    leaking blocks of memory in one of my methods. The function returns the
    data I expect, but I'm at a loss to understand why it leaks. Here is the
    function in question:

    -(NSArray*)itemsForElement:(NSString*)el{
        NSError* err = nil;
        NSString* searchString = [NSString stringWithFormat:@".//%@", el];
        NSArray* nodes = [self nodesForXPath:searchString error:&err];
        int i = 0;
        if([nodes count] == 0)
            return nil;

        NSMutableArray* values = [[NSMutableArray alloc] init];

        for(i; i < [nodes count]; i++){
            [values addObject:[[[nodes objectAtIndex:i] objectValue]
    stringByTrimmingCharactersInSet:[NSCharacterSet
    whitespaceAndNewlineCharacterSet]]];
        }

        return [values autorelease];

    }

    I don't call this function in a loop, only one time for a single
    element, but as you can see from the stack trace, I'm leaking 11 XQuery
    blocks although there can never be more than 7 items in the array. I
    searched Google looking for memory problems with nodesForXPath, but
    found nothing indicating an inherent problem with nodesForXPath. I found
    this in the archives though:
    http://lists.apple.com/archives/cocoa-dev/2005/Sep/msg01565.html
    The usage there is similar to mine, so assuming that's the correct way
    to use it, I should be OK.  I've included a portion of the MallocDebug
    dump file in case that helps.
    TIA

    STACK
    Address /098ca730/size/00000010
    0x0006a4f0  / 0x6a4f0 / libMallocDebug.A.dylib
    0x90c585d0  / _internal_class_createInstanceFromZone / libobjc.A.dylib
    0x94316b88  / +[NSObject allocWithZone:] / CoreFoundation
    0x0964b7d4  / 0x964b7d4 / XQuery
    0x09653278  / 0x9653278 / XQuery
    0x0963546c  / 0x963546c / XQuery
    0x09635d40  / 0x9635d40 / XQuery
    0x09635f60  / 0x9635f60 / XQuery
    0x09636dc8  / 0x9636dc8 / XQuery
    0x09635fcc  / 0x9635fcc / XQuery
    0x09636dc8  / 0x9636dc8 / XQuery
    0x09635c60  / 0x9635c60 / XQuery
    0x09645d84  / 0x9645d84 / XQuery
    0x09651bfc  / 0x9651bfc / XQuery
    0x92a43364  / -[NSXMLNode objectsForXQuery:constants:error:] / Foundation
    0x92a43024  / -[NSXMLNode nodesForXPath:error:] / Foundation
    0x00004c20  / -[WeatherParser valueForElement:atIndex:] / Weather Vane
    0x00007818  / -[WeatherVane tooltipData] / Weather Vane
    0x00007004  / -[WeatherVane parseData] / Weather Vane
    0x00006724  / -[WeatherVane parseAndUpdateData] / Weather Vane
    0x000022a8  / -[WeatherVane(WVURLConnection)
    connectionDidFinishLoading:] / Weather Vane
    0x929ff590  / _NSURLConnectionDidFinishLoading / Foundation
    0x963f9218  / sendDidFinishLoadingCallback / CFNetwork
    0x96414ee0  / handleCacheResponseIsValid / CFNetwork
    0x963f5e6c  / _CFURLConnectionSendCallbacks / CFNetwork
    0x963f5914  / muxerSourcePerform / CFNetwork
    0x942a239c  / CFRunLoopRunSpecific / CoreFoundation
    0x93d39ab8  / RunCurrentEventLoopInMode / HIToolbox
    0x93d398dc  / ReceiveNextEventCommon / HIToolbox
    0x93d3971c  / BlockUntilNextEventMatchingListInMode / HIToolbox
    0x90eac7a4  / _DPSNextEvent / AppKit
    0x90eac1f4  / -[NSApplication
    nextEventMatchingMask:untilDate:inMode:dequeue:] / AppKit
    0x90ea5eb0  / -[NSApplication run] / AppKit
    0x90e76930  / NSApplicationMain / AppKit
    0x00004054  / main / Weather Vane
    0x00001f64  / _start / Weather Vane
    0x00001c40  / start / Weather Vane
    ENDSTACK
  • On 22 Nov 2007, at 02:58, Lorenzo Thurman wrote:

    > I posted this on usenet, but still could not solve the problem.
    > Maybe someone here can help me:
    >
    > I have a subclass of NSXMLDocument that I use as an XMLParser. While
    > running my program through MallocDebug and Leaks, I see that I am
    > leaking blocks of memory in one of my methods.

    Are you sure these represent an actual memory leak?  Some code caches
    objects to avoid the allocation (and sometimes initialisation)
    overhead, so it may just be that these objects are in some sort of
    cache and will be re-used when you call -nodesForXPath:error: again.

    The way to check is to see whether repeatedly calling your -
    itemsForElement: method results in more and more XQuery blocks showing
    up in the list.  If it doesn't, they're probably in a cache.

    (These types of caches often don't get explicitly released, which is
    why they tend to show up as leaks when you're using leak-detection
    tools.)

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 22 Nov 2007, at 02:58, Lorenzo Thurman wrote:

    > I posted this on usenet, but still could not solve the problem.
    > Maybe someone here can help me:
    >
    > I have a subclass of NSXMLDocument that I use as an XMLParser. While
    > running my program through MallocDebug and Leaks

    I'll just add to what I just wrote.  Leaks (or the command line tool
    "leaks", or the Leaks instrument in Instruments) *should*, I think,
    only find genuine leaks.  If that's where you're getting the
    information from, then it looks like filing a bug report is the right
    thing to do.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Nov 22, 2007, at 4:19 a, Alastair Houghton wrote:

    > On 22 Nov 2007, at 02:58, Lorenzo Thurman wrote:
    >
    >> I posted this on usenet, but still could not solve the problem.
    >> Maybe someone here can help me:
    >>
    >> I have a subclass of NSXMLDocument that I use as an XMLParser.
    >> While running my program through MallocDebug and Leaks
    >
    > I'll just add to what I just wrote.  Leaks (or the command line tool
    > "leaks", or the Leaks instrument in Instruments) *should*, I think,
    > only find genuine leaks.  If that's where you're getting the
    > information from, then it looks like filing a bug report is the
    > right thing to do.
    >
    > Kind regards,
    >
    > Alastair.
    >
    > --
    > http://alastairs-place.net
    >
    >
    Thanks for the reply. I'm testing my subclass using a small program
    and Leaks shows no leaks at all, (I hate problems like this), so I
    think my problem must lie elsewhere. I'll do more testing and file a
    bug report if necessary and post again if I have anything new.

    "Mistakes are a part of being human. Appreciate your mistakes for what
    they are: precious life lessons that can only be learned the hard way.
    Unless it's a fatal mistake, which, at least, others can learn from."

      -- Al Franken

    Lorenzo Thurman
    <lorenzo...>
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today