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: PyArg_ParseTuple("s*") does not always incref object
Type: behavior Stage:
Components: Versions: Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: kristjan.jonsson, pitrou, python-dev, skrah, vstinner
Priority: normal Keywords: patch

Created on 2010-11-26 08:07 by kristjan.jonsson, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
#10538.patch kristjan.jonsson, 2012-03-22 16:02
Messages (8)
msg122445 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2010-11-26 08:07
The new "s*" code for PyArg_ParseTuple is used to fill a Py_buffer object from the arguments.  This object must be relased using PyBuffer_Release() after use.

However, if the object in the tuple does not support the new buffer interface, the old buffer interface is queried and the Py_buffer object is manually filled in.  For this case, the source object is _not_ increfed and buffer.obj remains set to 0.

This causes different semantics in the function for objects that are passed in:  If the Py_buffer interface is supported directly, then it is safe for the function to store this and release this at a later time.  If it isn't supported, then no extra reference to the object is got and the function cannot safely keep the Py_buffer object around.

The Fix is as follows:  Change line 1402 of getargs.c from:
PyBuffer_FillInfo(view, NULL, buf, count, 1, 0);
to
PyBuffer_FillInfo(view, arg, buf, count, 1, 0);
msg124098 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2010-12-16 01:06
Well, I can submit a patch if anyone is interested.
I came across this when writing asynchronous network code.  By hanging onto the Py_buffer, I should have access to the data during the network call.  But it only worked for "true" Py_buffer objects and not the others.
msg156582 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2012-03-22 16:02
Adding a patch here.
msg156587 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-22 16:18
Looks good to me.
msg156591 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-22 16:37
New changeset 17c671529f7e by Kristján Valur Jónsson in branch '2.7':
Issue #10538. Put a reference to the source object in the Py_buffer when
http://hg.python.org/cpython/rev/17c671529f7e
msg156597 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-03-22 17:28
You should mention your change in Misc/NEWS.
msg156614 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-22 20:20
New changeset 8efe88c0f14e by krisvale in branch '2.7':
Issue #10538 - Update Misc/NEWS
http://hg.python.org/cpython/rev/8efe88c0f14e
msg156617 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-03-22 20:34
Thanks :-)
History
Date User Action Args
2022-04-11 14:57:09adminsetgithub: 54747
2012-03-22 20:34:01vstinnersetmessages: + msg156617
2012-03-22 20:20:21python-devsetmessages: + msg156614
2012-03-22 17:28:47vstinnersetmessages: + msg156597
2012-03-22 16:38:31kristjan.jonssonsetstatus: open -> closed
resolution: fixed
2012-03-22 16:37:33python-devsetnosy: + python-dev
messages: + msg156591
2012-03-22 16:18:25pitrousetmessages: + msg156587
2012-03-22 16:02:21kristjan.jonssonsetfiles: + #10538.patch
keywords: + patch
messages: + msg156582
2012-03-20 09:24:06skrahsetnosy: + skrah
2010-12-16 01:06:42kristjan.jonssonsetnosy: pitrou, kristjan.jonsson, vstinner
messages: + msg124098
2010-12-15 20:40:12pitrousetassignee: pitrou ->
nosy: pitrou, kristjan.jonsson, vstinner
2010-11-26 14:18:11pitrousetnosy: + vstinner
2010-11-26 11:34:42georg.brandlsetassignee: pitrou

nosy: + pitrou
2010-11-26 08:07:59kristjan.jonssonsetversions: - Python 3.2
2010-11-26 08:07:31kristjan.jonssoncreate