New submission from hhas: While other CF...RefObj_Convert functions return a borrowed object, CFStringRefObj_Convert will return either a new or borrowed CFStringRef depending on the type of value supplied (str, unicode or CFString). As a result, extensions that use CFStringRefObj_Convert function to (e.g.) parse arguments - for example, Carbon.Launch (Launch_LSGetApplicationForInfo, Launch_LSFindApplicationForInfo) - will leak memory when a str or unicode value is passed.
Three possible solutions: 1. Make all CF...RefObj_Convert functions return a 'new' object (i.e. call CFRetain if returning an existing CF object) and make callers responsible for always calling CFRelease on these objects when done. 2. Make CFStringRefObj_Convert accept Carbon.CF.CFStringRef values only, and make users responsible for calling Carbon.CF.toCF on Python str/unicode values before passing them to extension functions. 3. Make no changes to existing code, but advise Python users to call Carbon.CF.toCF themselves before passing text values to extension functions whose docstrings specify CFStringRef parameters if they wish to avoid memory leaks. The third solution would be the obvious choice if future Python development plans call for the deprecation and eventual removal of Carbon.CF. If Carbon.CF is to retained in the long term, however, then some sort of fix would be preferable. While the other two solutions would inevitable cause some disruption, I would suggest #1 is the lesser evil as it would require only existing standard and 3rd-party C extensions to be modified, whereas #2 would require existing Python code to be modified which would affect end-users as well. Note that if solution #1 is used, callers would need to avoid invoking CFRelease when an older, unfixed version of Carbon.CF is in use as this would cause a memory error. This shouldn't cause a problem if the fix is made in a major Python release (whose extensions are incompatible with earlier versions, and vice-versa). pymactoolbox.h could supply a suitable macro, e.g.: #define CarbonCFRelease(v) if (v != NULL) CFRelease(v); which client code could invoke as: #ifdef CarbonCFRelease CarbonCFRelease(someRef); CarbonCFRelease(anotherRef); #endif Unpatched extensions would continue to leak (more) memory, of course, but there should be no other ill effects. ---------- components: Macintosh messages: 55846 nosy: hhas severity: normal status: open title: Carbon.CF memory management problem type: resource usage versions: Python 2.5 __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1155> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
