This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Carbon.CF memory management problem
Type: resource usage Stage:
Components: macOS Versions: Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: hhas, ronaldoussoren, terry.reedy
Priority: low Keywords:

Created on 2007-09-12 17:25 by hhas, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg55846 - (view) Author: (hhas) Date: 2007-09-12 17:25
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.
msg104550 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-04-29 18:07
Should this be closed? As out of date?
msg104576 - (view) Author: (hhas) Date: 2010-04-29 19:47
The Carbon extensions are deprecated in Python 2.6 and absent in Python 3, and PyObjC provides a far better alternative. I'd be surprised if this issue affects any users at this point (chances are I'm the only one who was ever bothered by it, and I eliminated all Carbon extension dependencies from my code in 2008). So I would recommend closing it as won't fix.
History
Date User Action Args
2022-04-11 14:56:26adminsetgithub: 45496
2010-04-29 20:40:56terry.reedysetstatus: open -> closed
resolution: wont fix
2010-04-29 19:47:50hhassetmessages: + msg104576
2010-04-29 18:07:10terry.reedysetstatus: pending -> open
nosy: + terry.reedy
messages: + msg104550

2009-04-07 04:04:53ajaksu2setstatus: open -> pending
nosy: + ronaldoussoren
versions: + Python 2.6, - Python 2.5

priority: normal -> low
2007-09-18 05:44:29jafosetpriority: normal
2007-09-12 17:25:51hhascreate