[New-bugs-announce] [issue1155] Carbon.CF memory management problem

[hhas]

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 <report at bugs.python.org>
<http://bugs.python.org/issue1155>
__________________________________