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: PyWeakref_GetObject
Type: crash Stage: resolved
Components: Interpreter Core, Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: arigo, georg.brandl, ghaering, jcon, loewis, pitrou, python-dev, vstinner
Priority: high Keywords:

Created on 2010-04-30 13:58 by arigo, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg104634 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2010-04-30 13:58
PyWeakref_GetObject(wref) returns a borrowed reference, but that's rather dangerous.  The fact that wref stays alive does not prevent the returned object from being collected (by definition -- wref is a weak reference).  That means that either we must explicitly and immediately do a Py_INCREF() (and later Py_DECREF()) on the result of the function, or we must use it for a very short time.

As an example of why this interface encourages buggy behavior, the sole user of PyWeakref_GetObject() in Module/* is Module/_sqlite/connection.c, which does

    statement = PyWeakref_GetObject(weakref);

and then call some functions passing 'statement' as argument.  The called functions can do anything (because they release the GIL).  So in particular they can cause 'statement' to be freed while still in use, either directly or indirectly via the cycle-GC.

This should be fixed; I suggest deprecating PyWeakref_GetObject() and adding another C API function that does not return a borrowed reference.
msg104637 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-30 14:13
> This should be fixed; I suggest deprecating PyWeakref_GetObject() and
> adding another C API function that does not return a borrowed reference.

Another possibility is to document the fact that Py_INCREF() should be called in most cases. It would be much lighter than a new API + deprecation process.

In the meantime, the sqlite issue should be fixed of course.
msg112504 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-08-02 17:49
I added a note to the docs in r83536.
msg137413 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-06-01 02:32
New changeset a856be6688a6 by Benjamin Peterson in branch '3.2':
be extra careful with a borrowed reference when the GIL could be released (closes #8578)
http://hg.python.org/cpython/rev/a856be6688a6
History
Date User Action Args
2022-04-11 14:57:00adminsetgithub: 52824
2011-06-01 02:32:06python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg137413

resolution: fixed
stage: resolved
2011-06-01 01:46:30jconsetnosy: + jcon
2010-08-02 17:49:31georg.brandlsetnosy: + georg.brandl
messages: + msg112504
2010-04-30 14:13:28pitrousetpriority: normal -> high
versions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2
nosy: + loewis, ghaering, vstinner, pitrou

messages: + msg104637

components: + Library (Lib)
2010-04-30 13:58:19arigocreate