• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Leaks in CFPropertyListCreateFromXMLData and CFFileURLCreateDataAndPropertiesFromResource?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Leaks in CFPropertyListCreateFromXMLData and CFFileURLCreateDataAndPropertiesFromResource?


  • Subject: Re: Leaks in CFPropertyListCreateFromXMLData and CFFileURLCreateDataAndPropertiesFromResource?
  • From: Chris Kane <email@hidden>
  • Date: Tue, 15 Apr 2003 10:00:34 -0700

leaks can tell you where the memory was allocated. It cannot tell you where it was leaked. (For example, where the missing free() or CFRelease() should be.)

The memory allocated by __CFPLDataDecode() for example is either freed, or given to a CFData to keep (NoCopy), along with the correct allocator with which to free the memory. The CFData then goes into a collection (probably), which may go into another collection and so on as the plist is parsed. At some point something may have extracted that data object from the resulting object graph and retained it, for example, and then failed to free it. One can reason *to some extent* that if there was a systematic bug down at the level in the plist parsing of data objects, then there would be a lot of leaks from the same source, since parsing plists is a very common operation in Mac OS X. [Similarly, for the first leak, that's probably part of a CFURL, which may have been leaked.]

So the first thing to do is recognize the contents of the bytes, as displayed by leaks (seems to be in large part uninitialized memory, though we don't know how long the data length actually was). If possible, that will often identify the source of the memory, and leak. In this case that doesn't look very hopeful. The next thing to try is to extract the key bits of plist parsing that you're doing into a small test program, and release the resulting top-level plist, and there should be few leaks. Put a call to pause() at the end of main() to keep the program from exiting so you can run leaks on it.


Chris Kane
Cocoa Frameworks, Apple


On Wednesday, March 26, 2003, at 06:35, Stiphane Sudre wrote:

This is what I'm seeing using the leaks tools.

The leaks are occurring apparently in CFPropertyListCreateFromXMLData when it needs to parse a CFData and for CFFileURLCreateDataAndPropertiesFromResource I don't have an opinion.

Leak: 0x000c3590 size=494 string '<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist ve'
Call stack: [thread 20e0bf]: | 0x0 | start | _start | main | ... | CFURLCreateDataAndPropertiesFromResource | _CFFileURLCreateDataAndPropertiesFromResource | _CFReadBytesFromFile | CFAllocatorAllocate | malloc_zone_malloc

Leak: 0x000b97b0 size=78
0x00000000 0x00000000 0x00000000 0x00000001
0x00000000 0x00000000 0xa1b1c1d3 0xa1b1c1d3
0xa1b1c1d3 0xa1b1c1d3 0xa1b1c1d3 0x73686f6c
0x642e706c 0x69737400 0xa1b1c1d3 0xa1b1c1d3
0xa1b1c1d3 0xa1b1c1d3 0xa1b1c1d3
Call stack: [thread 20e08b]: | 0x0 | start | _start | main | ... | _CFPropertyListCreateFromXMLData | parsePListTag | parseArrayTag | parseDataTag | __CFPLDataDecode | CFAllocatorAllocate | malloc_zone_malloc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Many sizes for the same NSImage
  • Next by Date: RE: Move Camera in OpenGL ?
  • Previous by thread: Many sizes for the same NSImage
  • Next by thread: Re: Newbie: Current Apps Directory
  • Index(es):
    • Date
    • Thread