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, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
