[Python-Dev] mac memory leaks

[Jack Jansen]

On 3 Jan 2006, at 08:58, Neal Norwitz wrote:

> I had a friend run regrtest -L on Mac OSX a while ago.  There are
> several memory leaks which still appear to be an issue.  There are a
> bunch of leaks reported from  putenv which I'm not sure how to fix
>
> The attached patch should correct one of the problems.  Can someone
> with a Mac test it?  I'll add to SF later if I don't get a response.
>
> n
> --
>
> I'm not sure about how to fix these or if they are real problems:
>
> Leak: 0x02541470  size=368      instance of 'NSCFData'
> Call stack: call_function | ici_ICFindPrefHandle | ICFindPrefHandle |
> OpaqueICInstance::FindPrefHandle(ICKeyInfo const&, unsigned long*,
> char**) | OpaqueICInstance::GetPref(ICKeyInfo const&, long, void*,
> long*, unsigned long*) | OpaqueICInstance::GetPrefCore(ICKeyInfo
> const&, long, void*, long*, unsigned long*) |
> OpaqueICInstance::LazyLoad() | ICCFPrefWrapper::ContainsPrefs() |
> ICCFPrefWrapper::GetPrefDictionary() | fetchXMLValue |
> _loadXMLDomainIfStale | _CFPropertyListCreateFromXMLData |
> __CFTryParseBinaryPlist | __CFBinaryPlistCreateObject |
> __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject |
> __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject |
> __CFDataInit | _CFRuntimeCreateInstance | CFAllocatorAllocate

This is somewhere down in the Internet Config builtin module, which  
would point to the webbrowser library module. My guess is that it's a  
singleton leak.
>
> Leak: 0x02506640  size=256
> Call stack: call_function | do_call | PyObject_Call | parser_st2tuple
> | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple |
> node2tuple | node2tuple | node2tuple | node2tuple | node2tuple |
> node2tuple | node2tuple | node2tuple | node2tuple | node2tuple |
> node2tuple | node2tuple | node2tuple | node2tuple | node2tuple |
> node2tuple | PyTuple_New | _PyObject_GC_NewVar | _PyObject_GC_Malloc |
> PyObject_Malloc | new_arena

No idea. There don't seem to be any mac-specific modules involved...

> Leak: 0x0118ad10  size=80
> Call stack: call_function | AE_AECreateDesc | AECreateDesc | operator
> new(unsigned long)

Hmm, the first candidates here would be test_aepack and  
test_scriptpackages, but neither one has an obvious leak (on cursory  
inspection). And actually, if there was a leak problem in either I  
would expect more than one AEDesc to be leaked.
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman