Oren Milman added the comment:
Oh, and calls to PyObject_GC_NewVar() might also cause similar issues.
--
___
Python tracker
<https://bugs.python.org/issue31
New submission from Oren Milman :
Given an uninitialized IncrementalNewlineDecoder:
uninitialized =
io.IncrementalNewlineDecoder.__new__(io.IncrementalNewlineDecoder)
each of the following calls would raise a SystemError ('null argument to
internal routine'):
uninitialize
Oren Milman added the comment:
Yes, although i don't know if there are usecases for that.
--
___
Python tracker
<https://bugs.python.org/issue31718>
___
___
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3886
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31718>
___
___
Python-
Oren Milman added the comment:
With regard to refleaks in __init__() methods, i started looking for similar
refleaks
in the codebase, and hope to open an issue to fix them soon.
--
___
Python tracker
<https://bugs.python.org/issue31
New submission from Oren Milman :
The following code causes an assertion failure in FutureObj_finalize() (in
Modules/_asynciomodule.c):
import asyncio
asyncio.Future()._log_traceback = True
Maybe we should allow Python code to only set it to False, and raise a
ValueError in case Python code
New submission from Oren Milman :
The following code causes refleaks:
import zipimport
zi = zipimport.zipimporter.__new__(zipimport.zipimporter)
zi.__init__('bar.zip')
zi.__init__('bar.zip')
zi.__init__('bar.zip\\foo')
This is because zipimport_zipimport
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3892
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31723>
___
___
Python-
New submission from Oren Milman :
The following code causes the interpreter to crash:
import xml.etree.ElementTree
class X:
def __del__(self):
elem.clear()
elem = xml.etree.ElementTree.Element('elem')
elem.text = X()
elem.clear()
This is because _elementtree_Element_
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3897
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31728>
___
___
Python-
New submission from Oren Milman :
The following code causes a crash:
import sqlite3
cache = sqlite3.Cache.__new__(sqlite3.Cache)
cache.get(None)
This is because pysqlite_cache_get() (in Modules/_sqlite/cache.c) assumes that
the Cache object is initialized, and so it passes self->mapping
Oren Milman added the comment:
Also, the following code results in a memory leak:
import sqlite3
cache = sqlite3.Cache.__new__(sqlite3.Cache)
This is because pysqlite_cache_dealloc() just returns in case of an
uninitialized
Cache object
Oren Milman added the comment:
Yes, i am going manually over the code to find similar stuff to #31718,
and i afraid i found quite a few, and still working on it..
--
___
Python tracker
<https://bugs.python.org/issue31
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3912
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31734>
___
___
Python-
New submission from Oren Milman :
The following code causes refleaks:
import sqlite3
connection = sqlite3.Connection.__new__(sqlite3.Connection)
connection.__init__('foo')
connection.__init__('foo')
This is because pysqlite_connection_init() (in Modules/_sqlite/connection.c
Oren Milman added the comment:
Ah, here also there are crashes when calling methods of uninitialized
connection objects.
Should i fix this as part of this issue, or open another one?
--
___
Python tracker
<https://bugs.python.org/issue31
Oren Milman added the comment:
As serhiy pointed out in a comment in PR 3924, setting self->text or self->tail
to
NULL might lead to an assertion failure, so we should also prevent the following
assertion failure (and the similar one for tail):
import xml.etree.ElementTree
class X:
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3917
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31740>
___
___
Python-
New submission from Oren Milman :
The following code causes a crash:
import sqlite3
connection = sqlite3.Connection.__new__(sqlite3.Connection)
connection.isolation_level
This is because pysqlite_connection_get_isolation_level() doesn't check whether
the Connection object is initia
Oren Milman added the comment:
(opened bpo-31746 for the crashes i mentioned)
--
___
Python tracker
<https://bugs.python.org/issue31740>
___
___
Python-bug
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3918
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31722>
___
___
Python-
Change by Oren Milman :
--
pull_requests: +3925
stage: backport needed -> patch review
___
Python tracker
<https://bugs.python.org/issue31728>
___
___
Python-
Change by Oren Milman :
--
pull_requests: +3926
stage: backport needed -> patch review
___
Python tracker
<https://bugs.python.org/issue31271>
___
___
Python-
Change by Oren Milman :
--
pull_requests: +3927
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue31490>
___
___
Python-bugs-lis
New submission from Oren Milman :
The following code results in refleaks:
import sys
import _elementtree
builder = _elementtree.TreeBuilder()
parser = _elementtree.XMLParser(target=builder)
refcount_before = sys.gettotalrefcount()
parser.__init__(target=builder)
print(sys.gettotalrefcount
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3931
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
New submission from Oren Milman :
The following code causes a crash:
import sqlite3
cursor = sqlite3.Cursor.__new__(sqlite3.Cursor)
cursor.close()
this is because pysqlite_cursor_close() (in Modules/_sqlite/cursor.c) assumes
that `self->connection` is not NULL, and passes it
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3934
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31764>
___
___
Python-
New submission from Oren Milman :
The following code crashes:
import sqlite3
import weakref
def callback(*args):
pass
connection = sqlite3.connect(":memory:")
cursor = sqlite3.Cursor(connection)
ref = weakref.ref(cursor, callback)
cursor.__init__(connection)
del cursor
del ref
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3946
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31770>
___
___
Python-
Oren Milman added the comment:
Shame on me. I only now found out that Serhiy already mentioned most of the
refleaks
in https://bugs.python.org/issue31455#msg302103.
--
___
Python tracker
<https://bugs.python.org/issue31
Oren Milman added the comment:
Serhiy, in addition to the problems you mentioned with not calling __init__(),
it seems
that calling every method of an uninitialized XMLParser object would crash.
If you don't mind, i would be happy to open an issue to fix these crashes.
--
nosy:
New submission from Oren Milman :
The following code causes an assertion failure:
import _struct
struct_obj = _struct.Struct.__new__(_struct.Struct)
struct_obj.iter_unpack(b'foo')
This is because Struct_iter_unpack() (in Modules/_struct.c) assumes that
Struct.__init__()
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3960
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31779>
___
___
Python-
New submission from Oren Milman :
The following code crashes:
import zipimport
zi = zipimport.zipimporter.__new__(zipimport.zipimporter)
zi.find_module('foo')
This is because get_module_info() (in Modules/zipimport.c) assumes that the
zipimporter object is initialized, so it assumes
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3962
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31781>
___
___
Python-
New submission from Oren Milman :
Various __init__() methods don't decref (if needed) before assigning to fields
of the object's struct (i.e. assigning to `self->some_field`):
- _asyncio_Task___init___impl() (in Modules/_asynciomodule.c)
- _lzma_LZMADecompressor___init___impl(
Change by Oren Milman :
--
keywords: +patch
pull_requests: +3971
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31787>
___
___
Python-
Oren Milman added the comment:
According to Serhiy's advice (https://bugs.python.org/issue31455#msg304338),
this issue now also includes some crashes in _elementtree:
The following code crashes:
import _elementtree
parser = _elementtree.XMLParser.__new__(_elementtree.XMLParser)
parser.
Change by Oren Milman :
--
pull_requests: +3972
___
Python tracker
<https://bugs.python.org/issue31758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Oren Milman added the comment:
ISTM that PR 3840 resolved this issue (as part of bpo-28280).
--
___
Python tracker
<https://bugs.python.org/issue31486>
___
___
Change by Oren Milman :
--
pull_requests: +4288
___
Python tracker
<https://bugs.python.org/issue31764>
___
___
Python-bugs-list mailing list
Unsubscribe:
Oren Milman added the comment:
I opened #4333 for 2.7, but it is quite straightforward.. Am i missing
something?
--
___
Python tracker
<https://bugs.python.org/issue31
Oren Milman added the comment:
The fix for issue #25659 already replaced the assertions in
CDataType_from_buffer and CDataType_from_buffer_copy with if statements (my
bad for missing that issue when I opened this one).
In addition, that fix added some tests, so I also added some, and created a
Oren Milman added the comment:
ping (just to close the issue, I think)
--
___
Python tracker
<http://bugs.python.org/issue28272>
___
___
Python-bugs-list mailin
Changes by Oren Milman :
--
pull_requests: +323
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Python-bugs-list mailing list
Unsubscribe:
Oren Milman added the comment:
I created a pull request (https://github.com/python/cpython/pull/392)
to fix the mistakes in _testcapimodule, but didn't mention this issue
in the pull request's title, as the issue mentioned these mistakes
only as a
Oren Milman added the comment:
the pull request was merged, so I guess we can close this issue..
--
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Oren Milman added the comment:
Do you mean that in each case PyArg_ParseTuple fails, we should chain
to the exception raised by PyArg_ParseTuple an exception that specifies
the name of the tuple that PyArg_ParseTuple failed to parse, without
specifying the function name
Oren Milman added the comment:
So, should I open a pull request?
(as some time had passed, I would also run again the tests, etc.)
--
___
Python tracker
<http://bugs.python.org/issue28
Oren Milman added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue28298>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Oren Milman:
the current state
>>> if is32BitCPython:
... PyLong_SHIFT = 15
... elif is64BitCPython:
... PyLong_SHIFT = 30
...
>>> # case A #
>>> a = 2 ** PyLong_SHIFT - 1
>>> b = 2 ** PyLong_SHIFT
Changes by Oren Milman :
Added file: http://bugs.python.org/file43042/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27145>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file43043/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27145>
___
___
Pytho
Oren Milman added the comment:
After giving it some more thought (while working on another, somewhat related
issue - http://bugs.python.org/issue27145), I realized that that assert in
long_add could further verify that the int x_add returned is a multiple-digit
int (as x_add had received two
Oren Milman added the comment:
And after quadruple checking myself, I found a foolish mistake - in that flow,
x_add received at least one multiple-digit int (not necessarily two :().
I fixed that mistake in the comment. The updated diff file is attached.
--
Added file: http
Oren Milman added the comment:
I agree. This assert only indirectly verifies that something bad doesn't
happen.
The bad thing that might happen is an in-place negating of an element of
small_ints, so the most direct assert should be 'assert(Py_REFCNT(z) == 1);'.
This is exac
Changes by Oren Milman :
Added file: http://bugs.python.org/file43145/patchedCPythonTestOutput2.txt
___
Python tracker
<http://bugs.python.org/issue27073>
___
___
Pytho
Oren Milman added the comment:
All right. The updated diff file is attached.
I compiled and ran the tests again. They are quite the same. The test output is
attached.
--
Added file: http://bugs.python.org/file43144/issue27073.diff
___
Python
Oren Milman added the comment:
I just realized I had forgotten to check for a failure after using
_PyLong_Negate. The updated diff file is attached.
--
Added file: http://bugs.python.org/file43148/proposedPatches.diff
___
Python tracker
<h
Oren Milman added the comment:
After giving it some more thought, I feel somewhat uncertain about that check
for a failure after using _PyLong_Negate.
At first I noticed that after every call to _PyLong_Negate there is such a
check. But then I realized that in my patch, and also in long_mul
Oren Milman added the comment:
I considered doing that, but I had already opened another issue
(http://bugs.python.org/issue27145) in which I had proposed to replace that
in-place negate in long_sub with a call to _PyLong_Negate.
But I guess I shouldn't worry about my patches coll
Changes by Oren Milman :
Added file: http://bugs.python.org/file43164/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27073>
___
___
Pytho
New submission from Oren Milman:
the current state
long_invert first checks whether v is a single-digit int. If it is, it simply
does 'return PyLong_FromLong(-(MEDIUM_VALUE(v) + 1));'.
Otherwise, long_invert does (edited for brevity) 'x = long_add(v,
Py
Changes by Oren Milman :
Added file: http://bugs.python.org/file43188/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27214>
___
___
Pytho
Changes by Oren Milman :
Added file: http://bugs.python.org/file43187/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27214>
___
___
Python-bug
New submission from Oren Milman:
current state
1. long_rshift first checks whether a is a negative int. If it is, it does
(edited for brevity) 'z = long_invert(long_rshift(long_invert(a), b));'.
Otherwise, it calculates the result of the shift and stores i
Changes by Oren Milman :
Added file: http://bugs.python.org/file43209/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27222>
___
___
Pytho
Changes by Oren Milman :
Added file: http://bugs.python.org/file43208/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27222>
___
___
Python-bug
Oren Milman added the comment:
done.
By the way, I am logging in to bugs.python.org through accounts.google.com, but
I couldn't see any way to do the same in www.python.org, so I have a native
account there (with the same email address). I hope that won't b
Changes by Oren Milman :
Added file: http://bugs.python.org/file43348/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Python-bug
New submission from Oren Milman:
current state
1. In Objects/longobject.c in _PyLong_AsUnsignedLongMask, in case v is a
multiple-digit int, _PyLong_AsUnsignedLongMask iterates over all of its digits
(going from the most to the least significant digit) and does (for
Changes by Oren Milman :
Added file: http://bugs.python.org/file43347/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Pytho
Oren Milman added the comment:
Ah, that's a cool alternative to divide and ceil. I would change my patch
accordingly.
And would write the patch also for _PyLong_AsUnsignedLongLongMask, and work on
some micro-benchmarking for it and _PyLong_AsUnsignedLongMask.
Indeed _testcapimodule.c i
Oren Milman added the comment:
I did some micro-benchmarking, and it looks like bad news for my patch.
I wrote a simple C extension in order to call PyLong_AsUnsignedLongMask and
PyLong_AsUnsignedLongLongMask from Python code (attached).
Then I ran the following micro-benchmarks using both the
Changes by Oren Milman :
Added file: http://bugs.python.org/file43434/badMicroBenchProposedPatches.diff
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Changes by Oren Milman :
Added file: http://bugs.python.org/file43435/proposedPatches.diff
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Python-bug
Oren Milman added the comment:
Except for some trailing spaces I have just found in my original proposed
patches, I don't have any extra changes to add. So as soon as Brett answers
about those two assignments, I would update and upload the patches diff file.
With regard to terminolo
Oren Milman added the comment:
Also, Brett was the one who added the three terms to the glossary in
https://hg.python.org/cpython/rev/ea5767ebd903, and a clarification of 'finder'
in https://hg.python.org/cpython/rev/88cee7d16ccb, so I guess his input in this
matter also would
New submission from Oren Milman:
current state
In six different functions, the following happens:
1. Function x calls _PyLong_New, with var y as the size argument.
* Among others, _PyLong_New sets the ob_size of the new int to y (the
size argument it
Changes by Oren Milman :
Added file: http://bugs.python.org/file43609/patchedCPythonTestOutput_ver1.txt
___
Python tracker
<http://bugs.python.org/issue27441>
___
___
Changes by Oren Milman :
--
keywords: +patch
Added file: http://bugs.python.org/file43608/issue27441_ver1.diff
___
Python tracker
<http://bugs.python.org/issue27
Changes by Oren Milman :
Added file: http://bugs.python.org/file43662/patchedCPythonTestOutput_ver2.txt
___
Python tracker
<http://bugs.python.org/issue27441>
___
___
Oren Milman added the comment:
I am sorry, but I can't see why micro-benchmarking is needed here, as my
patches only remove code that does nothing, while they don't add any new code.
The assembly the compiler generates (on my PC) for 'Py_SIZE(v) = negative ?
-ndigits
Oren Milman added the comment:
Note that http://bugs.python.org/issue26896 is now closed (the patches proposed
in it (with some minor changes) were committed).
--
nosy: +Oren Milman
___
Python tracker
<http://bugs.python.org/issue20
Oren Milman added the comment:
That's awesome! Thanks :)
--
___
Python tracker
<http://bugs.python.org/issue26896>
___
___
Python-bugs-list mailing list
Oren Milman added the comment:
I would be happy to write a patch for this issue, if you don't mind.
Terry, as you were the one to commit the patch for #21559, I guess you are OK
with keeping the OverflowError.
Also, I agree that the error message for '_testcapi.getargs_b(-1)' (a
Oren Milman added the comment:
ImpImporter was first added in changeset 37808
(https://hg.python.org/cpython/rev/ccc0b5412799) and updated a day later in
changeset 37821 (https://hg.python.org/cpython/rev/3135648026c4).
Both of these commits were introduced to support PEP 302.
Since then
Oren Milman added the comment:
Thanks for the review, Mark :)
--
___
Python tracker
<https://bugs.python.org/issue27214>
___
___
Python-bugs-list mailin
New submission from Oren Milman:
In Parser\tokenizer.c, in tok_get, in the identification of a potential NUMBER
token, in case the token starts with a '0', the next char of the token is
retrieved, followed by two redundant checks:
if (c == '.')
goto fraction;
if
Oren Milman added the comment:
Sorry for being so clueless.
The diff is attached.
I manually did some checks to verify that relevant stuff work correctly (the
imaginary number 0j, and fractions starting with '0.').
I run 'python -m test', and got the following output:
New submission from Oren Milman:
In Parser\parser.c in classify, the 'str' parameter is assigned into the local
variable 's'. However, 'str' is not used anywhere else in the function, which
makes 's' redundant.
My proposal is to simply remove '
New submission from Oren Milman:
the proposed changes:
1. it seems there is some mix-up with the terms 'importer' and 'finder' (and
rarely also 'loader') in the import system and in related code (I guess most of
it is just relics from the time before PEP 302)
Changes by Oren Milman :
Added file: http://bugs.python.org/file42667/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26896>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file42668/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26896>
___
___
Pytho
Oren Milman added the comment:
thanks for the review!
I replied to both of your comments, though I am not sure what is expected of me
in the rest of the process.
Whatever it is, I would be happy to help as much as I can.
--
___
Python tracker
New submission from Oren Milman:
the proposed changes:
I believe there are some mistakes in the following docstrings:
1. in Lib/importlib/_bootstrap.py:
- _module_repr - a typo
- _exec - I believe 'Execute the module specified by the spec' is more
accurate than &#
Changes by Oren Milman :
Added file: http://bugs.python.org/file42771/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26972>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file42772/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26972>
___
___
Pytho
New submission from Oren Milman:
the proposed changes
I believe the following checks are redundant:
1. in Objects/longobject.c in long_add:
In case both a and b are negative, their absolute values are added
using x_add, with the result stored in z
201 - 300 of 357 matches
Mail list logo
