Re: Leaks in CFPropertyListCreateFromXMLData and CFFileURLCreateDataAndPropertiesFromResource?
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.