Antoine Pitrou [EMAIL PROTECTED] added the comment:
Amaury, assuming you have tested it :-), the patch is ok to me. You can
commit.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Fixed in r66047.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Updated patch with the additional PyBuffer_Release mentioned by Neal,
plus a proposition of entry for the NEWS file.
There is no doc about the new interface, so no update is needed :-(
See issue2619.
Added file:
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
The main cause of these leaks is each time PyArg_ParseTuple(s#) is
passed a bytes object.
If FillInfo() increfs the given object, every object should have a
bf_releasebuffer that decrefs it.
___
Python
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Le dimanche 24 août 2008 à 09:18 +, Amaury Forgeot d'Arc a écrit :
If FillInfo() increfs the given object, every object should have a
bf_releasebuffer that decrefs it.
There's no need for that, PyBuffer_Release() does the decref.
But
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
This new version of the patch modifies getargs.c and use
PyObject_GetBuffer and PyBuffer_Release in place of the raw bf_getbuffer
and bf_releasebuffer.
Also make sure that each GetBuffer is matched with a ReleaseBuffer
(except for s* and
Neal Norwitz [EMAIL PROTECTED] added the comment:
Another PyBuffer_Release(pin); looks necessary at @@ -805,6 +807,7 @@.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
Neal Norwitz [EMAIL PROTECTED] added the comment:
Also there should be a Misc/NEWS entry added. Also check the doc to see
it needs updating wrt ownership.
--
type: - resource usage
___
Python tracker [EMAIL PROTECTED]
Antoine Pitrou [EMAIL PROTECTED] added the comment:
I don't know the buffer code to know if this is the correct fix.
However, it fixes the problems and that's probably good enough for now.
If you can get someone familiar with the buffer code to review, that
would be great.
I don't know if
Brett Cannon [EMAIL PROTECTED] added the comment:
Ignoring the question of whether owning the reference is the right thing
or not, the patch looks fine, although I don't see a reason for the
decrements to not be Py_DECREF since the function calls just won't even
happen if the object that the
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Hi,
Making Py_buffer INCREF the original object is IMO the right thing to
do, because in most cases letting the original object disappear means
the memory region will become invalid as well. If you don't want the
INCREF, you can pass NULL as
Neal Norwitz [EMAIL PROTECTED] added the comment:
This is a partial (or complete) duplicate of 3656.
--
nosy: +nnorwitz
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
New submission from Amaury Forgeot d'Arc [EMAIL PROTECTED]:
version 3.0, any call to eval() leaks one reference:
eval('1')
1
[42093 refs]
eval('1')
1
[42094 refs]
eval('1')
1
[42095 refs]
eval('1')
1
[42096 refs]
--
components: Interpreter Core
messages: 71783
nosy:
Christian Heimes [EMAIL PROTECTED] added the comment:
The error is inside compile, not eval:
compile(1, test, eval)
code object module at 0x7ffe1ce2ed50, file test, line 1
[43379 refs]
compile(1, test, eval)
code object module at 0x7ffe1ce2e3b0, file test, line 1
[43380 refs]
compile(1,
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
The leaked reference refers to the bytes object which encodes the code
being compiled:
for x in range(1000): compile(1, test, eval)
sys.getrefcount(b'1')
1004
___
Python tracker [EMAIL PROTECTED]
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Could it be related to the fact that test_bytes is leaking?
test_bytes leaked [129, 129, 129, 129] references, sum=516
--
nosy: +benjamin.peterson
___
Python tracker [EMAIL PROTECTED]
Christian Heimes [EMAIL PROTECTED] added the comment:
Good point! It's leaking even more on my 64bit machine:
test_bytes leaked [195, 195, 195, 195] references, sum=780
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
Christian Heimes [EMAIL PROTECTED] added the comment:
I was already up to date. r65985 leaks 195 references in each run on my box.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
The attached patch corrects the eval() and compile() reference leak.
The problem is in PyObject_AsReadBuffer.
Needs review: view-obj seems to own the reference, but object.h say the
opposite.
--
keywords: +needs review, patch
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
PyObject_AsCharBuffer is affected as well.
This fixes for me the last refleak in test_bytes.
Added file: http://bugs.python.org/file11224/buffer-leak.patch
___
Python tracker [EMAIL PROTECTED]
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11223/buffer-leak.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Of course, I forgot PyObject_AsWriteBuffer in my patch.
I wonder if turning view.obj into an owned reference was a good idea.
There are more calls to bf_getbuffer (in getarg.c), they leak too:
test_struct leaked [5, 5, 5, 5]
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11224/buffer-leak.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]:
--
assignee: - loewis
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3651
___
___
24 matches
Mail list logo
