[issue3651] eval() leaks 1 reference every time

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Fixed in r66047. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3651] eval() leaks 1 reference every time

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]> ___

[issue3651] eval() leaks 1 reference every time

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: http://bugs.python.org

[issue3651] eval() leaks 1 reference every time

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 kn

[issue3651] eval() leaks 1 reference every time

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]>

[issue3651] eval() leaks 1 reference every time

Neal Norwitz <[EMAIL PROTECTED]> added the comment: With the latest patch (and the one addition PyBuffer_Release() I noted above), valgrind is happy wrt memory leaks. The only problem valgrind found is a read of uninitialized memory. See http://bugs.python.org/issue3657 . I don't know the buff

[issue3651] eval() leaks 1 reference every time

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Another PyBuffer_Release(&pin); looks necessary at @@ -805,6 +807,7 @@. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3651] eval() leaks 1 reference every time

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

[issue3651] eval() leaks 1 reference every time

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

[issue3651] eval() leaks 1 reference every time

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. ___ Pyt

[issue3651] eval() leaks 1 reference every time

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Even with the patch, there are still tons of leaks. I don't know if it's due to the same problem or not. So far there is: test_unittest leaked [124, 124] references, sum=248 test_array leaked [110, 110] references, sum=220 test_audioop leaked

[issue3651] eval() leaks 1 reference every time

Neal Norwitz <[EMAIL PROTECTED]> added the comment: This is a partial (or complete) duplicate of 3656. -- nosy: +nnorwitz ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3651] eval() leaks 1 reference every time

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

[issue3651] eval() leaks 1 reference every time

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 bu

[issue3651] eval() leaks 1 reference every time

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: -- assignee: -> loewis nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3651] eval() leaks 1 reference every time

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11224/buffer-leak.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3651] eval() leaks 1 reference every time

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] reference

[issue3651] eval() leaks 1 reference every time

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11223/buffer-leak.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3651] eval() leaks 1 reference every time

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]>

[issue3651] eval() leaks 1 reference every time

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

[issue3651] eval() leaks 1 reference every time

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]> ___ _

[issue3651] eval() leaks 1 reference every time

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Benjamin: yes, test_bytes calls eval() 128 times. Christian: please "svn up", I just corrected another leak in bytesobject.c ___ Python tracker <[EMAIL PROTECTED]> _

[issue3651] eval() leaks 1 reference every time

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]> __

[issue3651] eval() leaks 1 reference every time

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]>

[issue3651] eval() leaks 1 reference every time

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

[issue3651] eval() leaks 1 reference every time

Christian Heimes <[EMAIL PROTECTED]> added the comment: The error is inside compile, not eval: >>> compile("1", "test", "eval") at 0x7ffe1ce2ed50, file "test", line 1> [43379 refs] >>> compile("1", "test", "eval") at 0x7ffe1ce2e3b0, file "test", line 1> [43380 refs] >>> compile("1", "test", "e

[issue3651] eval() leaks 1 reference every time

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: am