[New-bugs-announce] [issue1155] Carbon.CF memory management problem
report at bugs.python.org
Wed Sep 12 19:25:51 CEST 2007
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
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:
Unpatched extensions would continue to leak (more) memory, of course,
but there should be no other ill effects.
title: Carbon.CF memory management problem
type: resource usage
versions: Python 2.5
Tracker <report at bugs.python.org>
More information about the New-bugs-announce