[issue15988] Inconsistency in overflow error messages of integer argument
Oren Milman added the comment: How do we proceed? should I update (if needed) each of the patches I uploaded in March to eliminate commit conflicts? or can someone review them as they are now? -- ___ Python tracker <http://bugs.python.org/issue15988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31147] a mostly useless check in list_extend()
New submission from Oren Milman:
in listobject.c, in case list_extend() receives an 'iterable' which isn't 'self'
nor a tuple nor a list, we have the following (heavily edited for brevity):
mn = Py_SIZE(self) + PyObject_LengthHint(iterable);
list_resize(self, mn);
... // self is extended to also include the elements of 'iterable'.
// (*)
if (Py_SIZE(self) < self->allocated) {
list_resize(self, Py_SIZE(self));
}
IMHO, the condition in (*) is mostly useless, for two reasons:
1. the list_resize() which is called in (*) does nothing in case
(Py_SIZE(self) >= (self->allocated >> 1)) is true. In particular, this call
to list_resize() would have done nothing if it had been called while the
condition in (*) was false.
2. the condition in (*) is false only in the following cases:
- list_resize(self, mn) caused
(self->allocated == Py_SIZE(self) + actual_length_of_iterable) to be
true. e.g.:
Py_SIZE(self) = 58 and PyObject_LengthHint(iterable) == 8 and
actual_length_of_iterable == 22
(because 66 + 66 // 8 + 6 == 80 == 58 + 22).
- list_resize(self, mn) caused
(self->allocated < Py_SIZE(self) + actual_length_of_iterable), which
sometime later caused list_extend() to call app1(), which called
list_resize(), which caused
(self->allocated == Py_SIZE(self) + actual_length_of_iterable) to be true.
e.g.:
Py_SIZE(self) == 58 and PyObject_LengthHint(iterable) == 8 and
actual_length_of_iterable == 39
(because 66 + 66 // 8 + 6 == 80 and
81 + 81 // 8 + 6 == 97 == 58 + 39)
so ISTM that the condition is only rarely false, especially as
PyObject_LengthHint(iterable) >= actual_length_of_iterable is usually true
(i guess).
Thus, i believe we should either change the condition in (*) to
(Py_SIZE(self) < (self->allocated >> 1)), or remove it (and always call
list_resize()).
(note that i ignored error cases, as ISTM they are quite irrelevant to the
issue.)
--
components: Interpreter Core
messages: 299933
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: a mostly useless check in list_extend()
type: performance
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31147>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31187] suboptimal code in Py_ReprEnter()
New submission from Oren Milman:
in Objects/object.c, Py_ReprEnter() does the following:
- try to retrieve the Py_Repr list from the thread-state dict.
- in case the list is not in the dict, add it to the dict as an empty list.
- check whether the received object is in the Py_Repr list, even in case the
list was just created, and guaranteed to be empty.
I propose to put this check inside an else clause, so that it wouldn't take
place in case the list is guaranteed to be empty, i.e.:
list = _PyDict_GetItemId(dict, &PyId_Py_Repr);
if (list == NULL) {
list = PyList_New(0);
...
}
else {
i = PyList_GET_SIZE(list);
while (--i >= 0) {
if (PyList_GET_ITEM(list, i) == obj)
return 1;
}
}
I ran the test suite, and it seems that this change doesn't break anything, so
I would be happy to open a PR for it.
--
components: Interpreter Core
messages: 300193
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: suboptimal code in Py_ReprEnter()
type: performance
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31187>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31147] a suboptimal check in list_extend()
Changes by Oren Milman : -- title: a mostly useless check in list_extend() -> a suboptimal check in list_extend() ___ Python tracker <http://bugs.python.org/issue31147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31147] a suboptimal check in list_extend()
Oren Milman added the comment: thank you for the elaborate reply :) do you feel the same about changing the check to (Py_SIZE(self) < (self->allocated >> 1)) ? -- ___ Python tracker <http://bugs.python.org/issue31147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: I replied to your comments in Rietveld, Serhiy. (http://bugs.python.org/review/28261) also, i found two places with a quite similar issue: - in Objects/exceptions.c in ImportError_init: >>> ImportError(1, 2, 3, 4, a=5, b=6, c=7) Traceback (most recent call last): File "", line 1, in TypeError: ImportError() takes at most 2 arguments (3 given) - in Python/bltinmodule.c in min_max: >>> min(1, 2, 3, 4, a=5, b=6, c=7) Traceback (most recent call last): File "", line 1, in TypeError: function takes at most 2 arguments (3 given) may I fix them also as part of this issue? -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: After more looking, I found this issue in two more places: - in Modules/itertoolsmodule.c in product_new: >>> itertools.product(0, a=1, b=2, c=3, d=4, e=5, f=6) Traceback (most recent call last): File "", line 1, in TypeError: product() takes at most 1 argument (6 given) - in Python/bltinmodule.c in builtin_print: >>> print(0, a=1, b=2, c=3, d=4, e=5, f=6) Traceback (most recent call last): File "", line 1, in TypeError: print() takes at most 4 arguments (6 given) what do you think? should I open another issue for these and the other two I mentioned in msg300366? -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28332] silent truncations in socket.htons and socket.ntohs
Changes by Oren Milman : -- title: Deprecated silent truncations in socket.htons and socket.ntohs. -> silent truncations in socket.htons and socket.ntohs ___ Python tracker <http://bugs.python.org/issue28332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28332] keyword arguments
Changes by Oren Milman : -- title: silent truncations in socket.htons and socket.ntohs -> keyword arguments ___ Python tracker <http://bugs.python.org/issue28332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28332] Deprecated silent truncations in socket.htons and socket.ntohs.
Changes by Oren Milman : -- title: keyword arguments -> Deprecated silent truncations in socket.htons and socket.ntohs. ___ Python tracker <http://bugs.python.org/issue28332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3157 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
New submission from Oren Milman: Some functions produce wrong error messages in case they receive too many keyword arguments: - in Objects/exceptions.c - ImportError_init: >>> ImportError(1, 2, 3, 4, a=5, b=6, c=7) TypeError: ImportError() takes at most 2 arguments (3 given) - in Python/bltinmodule.c - min_max: >>> min(1, 2, 3, 4, a=5, b=6, c=7) TypeError: function takes at most 2 arguments (3 given) >>> max(1, 2, 3, 4, a=5, b=6, c=7) TypeError: function takes at most 2 arguments (3 given) - in Modules/itertoolsmodule.c - product_new: >>> itertools.product(0, a=1, b=2, c=3, d=4, e=5, f=6) TypeError: product() takes at most 1 argument (6 given) - in Python/bltinmodule.c - builtin_print: >>> print(0, a=1, b=2, c=3, d=4, e=5, f=6) TypeError: print() takes at most 4 arguments (6 given) ISTM that changing these error messages to refer to 'keyword arguments' instead of 'arguments' is a possible solution. (e.g. the last one would become 'print() takes at most 4 keyword arguments (6 given)' To do that, I changed two 'takes at most' PyErr_Format calls in Python/getargs.c. I ran the test suite, and it seems that this patch doesn't break anything. The diff file is attached. (I didn't open a PR before hearing your opinion, as ISTM that changing code in getargs.c is a delicate thing.) what do you think? -- components: Interpreter Core messages: 300451 nosy: Oren Milman priority: normal severity: normal status: open title: wrong error messages when too many kwargs are received type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
Changes by Oren Milman : -- keywords: +patch Added file: http://bugs.python.org/file47091/issue31229_ver1.diff ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31236] improve some error messages of min() and max()
New submission from Oren Milman: currently, we have the following: >>> min(0, a=1) TypeError: 'a' is an invalid keyword argument for this function >>> max(0, a=1) TypeError: 'a' is an invalid keyword argument for this function >>> max(0, a=1, b=2, c=3) TypeError: function takes at most 2 arguments (3 given) >>> min(0, a=1, b=2, c=3) TypeError: function takes at most 2 arguments (3 given) ISTM it would be preferable for min() and max() to have error messages similar to those of int(): >>> int(0, a=1) TypeError: 'a' is an invalid keyword argument for int() >>> int(0, a=1, b=2) TypeError: int() takes at most 2 arguments (3 given) we can achieve this by making a small change in Python/bltinmodule.c in min_max (I would open a PR soon), and by resolving #31229. -- components: IO messages: 300539 nosy: Oren Milman priority: normal severity: normal status: open title: improve some error messages of min() and max() type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31236] improve some error messages of min() and max()
Changes by Oren Milman : -- pull_requests: +3181 ___ Python tracker <http://bugs.python.org/issue31236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29843] errors raised by ctypes.Array for invalid _length_ attribute
Oren Milman added the comment: I am not sure I understood your question, Igor. I compiled with https://github.com/python/cpython/pull/3006, and got: class T(ctypes.Array): _type_ = ctypes.c_int _length_ = 2 ** 1000 Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C ssize_t and also: class T(ctypes.Array): _type_ = ctypes.c_int _length_ = -1 Traceback (most recent call last): File "", line 1, in OverflowError: array too large -- ___ Python tracker <http://bugs.python.org/issue29843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29832] Don't refer to getsockaddrarg in error messages
Changes by Oren Milman : -- pull_requests: +3199 ___ Python tracker <http://bugs.python.org/issue29832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29832] Don't refer to getsockaddrarg in error messages
Oren Milman added the comment: here is a dirty script to test my PR. the script contains tests to anything I managed to test using my Windows 10 and Ubuntu 16.04 VM, i.e. all of the changes, except for the 'unsupported CAN protocol' message, and the changes of the code that handles the PF_SYSTEM family. -- Added file: http://bugs.python.org/file47093/testPatches.py ___ Python tracker <http://bugs.python.org/issue29832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
New submission from Oren Milman:
according to the docs
(https://docs.python.org/3.7/c-api/arg.html?highlight=pyarg_parsetuple#c.PyArg_ParseTuple),
PyArg_ParseTuple
returns true for success or false for failure. I also looked at the
implementation in Python/getargs.c, and it seems that indeed PyArg_ParseTuple
can return only 0 or 1.
however, in some places in the codebase, there are checks whether
PyArg_ParseTuple returned a negative int.
I found a bunch in Modules/_testcapimodule.c, and one in Modules/_io/textio.c
in textiowrapper_read_chunk. (hopefully i haven't missed other places.)
this code crashes because of the check in textiowrapper_read_chunk:
import codecs
import _io
class MyDec():
def getstate(self):
return 420
class MyDecWrapper():
def __call__(self, blabla):
return MyDec()
quopri = codecs.lookup("quopri")
quopri._is_text_encoding = True
quopri.incrementaldecoder = MyDecWrapper()
t = _io.TextIOWrapper(_io.BytesIO(b'aa'),
newline='\n', encoding="quopri")
t.read(42)
I guess all of these checks should be changed to check whether PyArg_ParseTuple
returned 0.
also, before this specific call to PyArg_ParseTuple in textiowrapper_read_chunk,
we should check whether 'state' is a tuple.
Moreover, this call shouldn't produce a wrong error message, as explained in
#28261.
------
components: Interpreter Core
messages: 300613
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: checks whether PyArg_ParseTuple returned a negative int
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31243>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: it seems that I have missed some places which are part of this issue, at least in Modules/_io/textio.c (one of them is mentioned in #31243). also, when fixing these, we should also add a check before the call to PyArg_ParseTuple (in case such check doesn't already exist), to verify the object is indeed a tuple. -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Oren Milman added the comment: yes, soon. (just wanted to hear your opinion before doing that.) -- ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
Oren Milman added the comment: I already wrote a patch, but I thought it would be better to wait until #31236 is resolved. this is because #31236 would change the error messages of min() and max(), and test_call tests exact error messages in CFunctionCallsErrorMessages, which is where I thought the tests of this issue should be added. -- ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Changes by Oren Milman : -- pull_requests: +3208 ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
Changes by Oren Milman : -- pull_requests: +3218 ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3237 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
New submission from Oren Milman:
currently, the following causes an assertion in Modules/_io/textio.c in
_io_TextIOWrapper_write_impl() to fail:
import codecs
import io
class BadEncoder():
def encode(self, dummy):
return 42
def _get_bad_encoder(dummy):
return BadEncoder()
quopri = codecs.lookup("quopri")
quopri._is_text_encoding = True
quopri.incrementalencoder = _get_bad_encoder
t = io.TextIOWrapper(io.BytesIO(b'foo'), encoding="quopri")
t.write('bar')
this is because _io_TextIOWrapper_write_impl() doesn't check whether the value
returned by encoder's encode() is a bytes object.
(I would open a PR to fix that soon.)
------
components: IO
messages: 300795
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: an assertion failure in io.TextIOWrapper.write
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31271>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Changes by Oren Milman : -- pull_requests: +3240 ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Oren Milman added the comment: Just checked on current 3.6 on my Windows 10. The assertion failes, and it is in line 1337. oh my. -- ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Oren Milman added the comment:
As Serhiy pointed out on github, the assertion failure can be easily reproduced
by the following:
import codecs
import io
rot13 = codecs.lookup("rot13")
rot13._is_text_encoding = True
t = io.TextIOWrapper(io.BytesIO(b'foo'), encoding="rot13")
t.write('bar')
--
___
Python tracker
<http://bugs.python.org/issue31271>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: sure -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Oren Milman added the comment: all three versions do 'self->pending_bytes_count += PyBytes_GET_SIZE(b);', while 'b' is the object the encoder returned. in 3.6 and 3.7, the implementation of PyBytes_GET_SIZE() includes 'assert(PyBytes_Check(op))', but in 2.7, the implementation is 'PyString_GET_SIZE', which is just 'Py_SIZE(op)'. and so, in 2.7 there isn't an assertion failure. Moreover, 'self->pending_bytes_count' is used only to determine whether a flush is needed. so ISTM that probably the bug's only risk is not flushing automatically after writing. note that whenever _textiowrapper_writeflush() is finally called (when the encoder returned a non-string object), it would raise a TypeError by calling string_join() on a non-string object. do you still think we should backport to 2.7? -- ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Changes by Oren Milman : -- pull_requests: +3247 ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3248 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3251 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
New submission from Oren Milman:
1.
the following causes an assertion failure in Python/_warnings.c in
show_warning():
import warnings
class BadLoader:
def get_source(self, fullname):
class BadSource:
def splitlines(self):
return [42]
return BadSource()
del warnings._showwarnmsg
warnings.warn_explicit(message='foo', category=ArithmeticError, filename='bar',
lineno=1, module_globals={'__loader__': BadLoader(),
'__name__': 'foobar'})
in short, the assertion failure would happen in warnings.warn_explicit() in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1]
is not a str.
2.
the following raises a SystemError:
import warnings
class BadLoader:
def get_source(self, fullname):
class BadSource:
def splitlines(self):
return 42
return BadSource()
warnings.warn_explicit(message='foo', category=UserWarning, filename='bar',
lineno=42, module_globals={'__loader__': BadLoader(),
'__name__': 'foobar'})
in short, warnings.warn_explicit() raises the SystemError in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()
is not a list.
ISTM that adding a check in warnings_warn_explicit() (in Python/_warnings.c),
to check whether
module_globals['__loader__'].get_source(module_globals['__name__'])
is a str (after existing code found out that it isn't None) would prevent both
the assertion failure and the SystemError.
What do you think? Is it OK to permit get_source() to return only None or a str?
--
components: Interpreter Core
messages: 300892
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: a SystemError and an assertion failure in warnings.warn_explicit()
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31285>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
Oren Milman added the comment: on a second thought, BadSource could be a subclass of str, so maybe we should just check whether module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1] is a str, and whether module_globals['__loader__'].get_source(module_globals['__name__']).splitlines() is a list. -- ___ Python tracker <http://bugs.python.org/issue31285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
Changes by Oren Milman : -- pull_requests: +3259 ___ Python tracker <http://bugs.python.org/issue31285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
New submission from Oren Milman:
on Windows, assuming the file 'foo.zip' exists, the following would cause an
assertion failure in Modules/zipimport.c in
zipimport_zipimporter_get_data_impl():
import zipimport
class BadStr(str):
def replace(self, old, new):
return 42
zipimport.zipimporter('foo.zip').get_data(BadStr('bar'))
this is because zipimport_zipimporter_get_data_impl() assumes that
BadStr('bar').replace('/', '\\') is a string.
------
components: Interpreter Core
messages: 300944
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: an assertion failure in zipimport.zipimporter.get_data()
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
Changes by Oren Milman : -- pull_requests: +3269 ___ Python tracker <http://bugs.python.org/issue31291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
Oren Milman added the comment: ISTM that your solution is better than mine, Serhiy, so I updated the PR. -- ___ Python tracker <http://bugs.python.org/issue31285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
New submission from Oren Milman: both of the following true division and multiplication operations crash the interpreter: import datetime class BadFloat(float): def as_integer_ratio(self): return (1 << 1000) - 1 datetime.timedelta() / BadFloat() datetime.timedelta() * BadFloat() this is because both multiply_float_timedelta() and truedivide_timedelta_float() (in Modules/_datetimemodule.c) assume as_integer_ratio() returns tuple. -- components: Interpreter Core messages: 300954 nosy: Oren Milman priority: normal severity: normal status: open title: crashes in multiply_float_timedelta() and in truedivide_timedelta_float() type: crash versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
Oren Milman added the comment: i am working on a patch. BTW, is there anywhere a list of what counts as an extension module, and what counts as the interpreter core? -- ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
Changes by Oren Milman : -- pull_requests: +3270 ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
Oren Milman added the comment: I guess you meant for me to check whether the following has any problem: import decimal class BadFloat(float): def as_integer_ratio(self): return 1 << 1000 decimal.Decimal.from_float(BadFloat()) so it doesn't crash. if IIUC, this is because the C implementation of Decimal.from_float() is PyDecType_FromFloat(), while the relevant part of it is a call to PyDecType_FromFloatExact(). But PyDecType_FromFloatExact() uses float.as_integer_ratio(), and thus ISTM that the issue doesn't exist there. (also, the following doesn't raise an exception, as expected: import decimal class BadFloat(float): def as_integer_ratio(self): raise RuntimeError decimal.Decimal.from_float(BadFloat()) ) -- ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
Oren Milman added the comment: I understand that our goal is to make Python better, not to make me happier :) anyway, I haven't checked, but I am quite sure that similar code might crash the interpreter on a release build of Python. (just wanted to clarify that, as you used the term 'exception'.) -- ___ Python tracker <http://bugs.python.org/issue31291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
Oren Milman added the comment:
just checked, and indeed on my Windows 10 the original code I posted here
crashes the interpreter.
The patch in the PR undermines duck-typing, and that's why I added a comment
there, stating I wasn't sure about the patch.
an alternate solution would be to simply check whether the return value of
pathname.replace('/', '\') is a str.
do you think I would update the PR to do that?
--
___
Python tracker
<http://bugs.python.org/issue31291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Changes by Oren Milman : -- pull_requests: +3275 ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Changes by Oren Milman : -- pull_requests: +3276 ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] zipimport.zipimporter.get_data() crashes when path.replace() returns a non-str
Changes by Oren Milman : -- pull_requests: +3287 ___ Python tracker <http://bugs.python.org/issue31291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] SystemError raised by PyCData_setstate() in case __dict__ is not a dict
New submission from Oren Milman:
The following code causes PyCData_setstate() (in Modules/_ctypes/_ctypes.c) to
raise a SystemError:
import ctypes
class BadStruct(ctypes.Structure):
def __dict__(self):
pass
BadStruct().__setstate__({}, b'foo')
this is because PyCData_setstate() assumes that the __dict__ attribute is a
dict.
while we are here, I wonder whether we should change the format given to
PyArg_ParseTuple() to "!Os#", so that the following would raise a TypeError:
import ctypes
class MyStruct(ctypes.Structure):
pass
MyStruct().__setstate__(42, b'foo')
AttributeError: 'int' object has no attribute 'keys'
what do you think?
--
components: Extension Modules
messages: 301034
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: SystemError raised by PyCData_setstate() in case __dict__ is not a dict
type: behavior
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31311>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] SystemError raised by PyCData_setstate() in case __dict__ is not a dict
Oren Milman added the comment: typo - change the format to "O!s#" -- ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- title: SystemError raised by PyCData_setstate() in case __dict__ is not a dict -> a SystemError and a crash in PyCData_setstate() when __dict__ is bad ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- pull_requests: +3298 ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- pull_requests: +3299 ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- components: +ctypes -Extension Modules ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31315] assertion failure in imp.create_dynamic(), when spec.name is not a string
New submission from Oren Milman: The following code causes an assertion failure in get_encoded_name(), which is called by _PyImport_LoadDynamicModuleWithSpec() (in Python/importdl.c): import imp class BadSpec: name = 42 origin = 'foo' imp.create_dynamic(BadSpec()) this is because _PyImport_LoadDynamicModuleWithSpec() assumes that spec.name is a string. should we fix this (even though imp is deprecated)? -- components: Extension Modules messages: 301050 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in imp.create_dynamic(), when spec.name is not a string type: crash versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31315] assertion failure in imp.create_dynamic(), when spec.name is not a string
Oren Milman added the comment: do you mean that we should fix it to raise a TypeError? the assertion is there, but not explicitly. get_encoded_name() calls PyUnicode_FindChar(), which calls PyUnicode_READY(), which does assert(_PyUnicode_CHECK). so i get: >>> import imp >>> >>> class BadSpec: ... name = 42 ... origin = 'foo' ... >>> imp.create_dynamic(BadSpec()) Assertion failed: PyUnicode_Check(op), file ..\Objects\unicodeobject.c, line 380 -- ___ Python tracker <http://bugs.python.org/issue31315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31315] assertion failure in imp.create_dynamic(), when spec.name is not a string
Changes by Oren Milman : -- pull_requests: +3301 ___ Python tracker <http://bugs.python.org/issue31315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31404] undefined behavior and crashes in case of a bad sys.modules
New submission from Oren Milman: at least on my Windows, the following code: import sys sys.modules = [] - when run interactively, causes weird behavior, e.g. exit() doesn't exit the interpreter, and print() doesn't print. then, pressing Ctrl+C causes 'Assertion failed: !PyErr_Occurred(), file ..\Objects\call.c, line 803' - when run as a script, causes PyImport_Cleanup() to raise a negative ref count Fatal Python error. (this is because PyImport_Cleanup() (in Python/import.c) assumes that PyImport_GetModuleDict() returned a dict.) IIUC, this bug was introduced in https://github.com/python/cpython/pull/1638 (which resolved #28411). -- components: Interpreter Core messages: 301783 nosy: Oren Milman priority: normal severity: normal status: open title: undefined behavior and crashes in case of a bad sys.modules type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Oren Milman added the comment: just in case it was missed - I have opened two PRs for this issue. -- ___ Python tracker <https://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31406] crashes when comparing between a Decimal object and a bad Rational object
New submission from Oren Milman: The following code crashes the interpreter: import decimal import fractions class BadRational(fractions.Fraction): numerator = None denominator = 42 decimal.Decimal() < BadRational() this is because numerator_as_decimal() (in Modules/_decimal/_decimal.c) assumes that 'numerator' is an integer. multiply_by_denominator() (in Modules/_decimal/_decimal.c) also assumes that 'denominator' is an integer, and so the following code crashes the interpreter: import decimal import fractions class BadRational(fractions.Fraction): numerator = 42 denominator = None decimal.Decimal() < BadRational() -- components: Extension Modules messages: 301809 nosy: Oren Milman priority: normal severity: normal status: open title: crashes when comparing between a Decimal object and a bad Rational object type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31406] crashes when comparing between a Decimal object and a bad Rational object
Changes by Oren Milman : -- keywords: +patch pull_requests: +3467 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31411] SystemError raised by warn_explicit() in case warnings.onceregistry is not a dict
New submission from Oren Milman:
The following code causes warn_explicit() (in Python/_warnings.c) to raise a
SystemError:
import warnings
warnings.filterwarnings('once')
warnings.onceregistry = None
warnings.warn_explicit(message='foo', category=Warning, filename='bar',
lineno=1, registry=None)
this is because warn_explicit() assumes that warnings.onceregistry is a dict,
and passes it to update_registry(), which passes it to already_warned(), which
eventually passes it to _PyDict_SetItemId(), which raises the SystemError.
--
components: Extension Modules
messages: 301822
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: SystemError raised by warn_explicit() in case warnings.onceregistry is
not a dict
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31411>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31411] SystemError raised by warn_explicit() in case warnings.onceregistry is not a dict
Changes by Oren Milman : -- keywords: +patch pull_requests: +3475 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31416] assertion failures in warn_explicit() in case of a bad warnings.filters or warnings.defaultaction
New submission from Oren Milman: The following code causes an assertion failure in warn_explicit() (in Python/_warnings.c): import warnings warnings.filters = [(None, None, Warning, None, 0)] warnings.warn_explicit(message='foo', category=Warning, filename='bar', lineno=1) this is because warn_explicit() assumes that get_filter() returned a string, and passes the return value (of get_filter()) to _PyUnicode_EqualToASCIIString(), which asserts it received a string. In addition, get_filter() might return warnings.defaultaction, and so the following code also causes an assertion failure in warn_explicit(): import warnings warnings.defaultaction = None warnings.filters = [] warnings.warn_explicit(message='foo', category=Warning, filename='bar', lineno=1) -- components: Extension Modules messages: 301867 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failures in warn_explicit() in case of a bad warnings.filters or warnings.defaultaction type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31416] assertion failures in warn_explicit() in case of a bad warnings.filters or warnings.defaultaction
Changes by Oren Milman : -- keywords: +patch pull_requests: +3489 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31418] assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__
New submission from Oren Milman: The following code causes an assertion failure in PyErr_WriteUnraisable() (in Python/errors.c): class BadException(Exception): __module__ = None class BadClass: def __del__(self): raise BadException foo = BadClass() del foo this is because PyErr_WriteUnraisable() assumes that __module__ is a string, and passes it to _PyUnicode_EqualToASCIIId(), which asserts it received a string. what is the wanted behavior in such a case? should we ignore the bad __module__ and print '' as the module name in the traceback? -- components: Interpreter Core messages: 301872 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__ type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo
New submission from Oren Milman:
The following code causes ElementTree.Element.__deepcopy__() to raise a
SystemError:
class BadMemo:
def get(*args):
return None
import xml.etree.ElementTree
xml.etree.ElementTree.Element('foo').__deepcopy__(BadMemo())
this is because _elementtree_Element___deepcopy__() (in Modules/_elementtree.c)
assumes that memo is a dictionary, and passes it to PyDict_SetItem(), which
raises the SystemError.
--
components: XML
messages: 301953
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad
memo
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo
Changes by Oren Milman : -- keywords: +patch pull_requests: +3507 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue31428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31442] assertion failures on Windows in Python/traceback.c in case of a bad io.open
New submission from Oren Milman: the following code causes an assertion failure on my Windows: import io def _bad_open(*args): return 42 io.open = _bad_open 1/0 this is because _Py_DisplaySourceLine() (in Python/traceback.c) assumes that the return value of io.open() is valid. IIUC, this is actually a debug assertion failure in Windows code, in _get_osfhandle() (which is called by _Py_dup() (in Python/fileutils.c)). (also, on my Ubuntu VM, there is no assertion failure.) the following code causes a similar assertion failure: import io def _bad_open1(*args): io.open = _bad_open2 raise Exception def _bad_open2(*args): return 42 io.open = _bad_open1 1/0 this is because _Py_FindSourceFile() assumes that the return value of io.open() is valid, and returns it to _Py_DisplaySourceLine(), which also assume it is valid. I thought about adding a check in _Py_DisplaySourceLine(), before calling PyObject_AsFileDescriptor(), such as: PyObject_IsInstance(binary, (PyObject*)&PyIOBase_Type); but I am not sure whether we should use PyIOBase_Type outside of the io module. note that even with such a check, one could still write a _bad_open() that returns a subclass of IOBase, whose fileno() method returns a bad file descriptor. #15263 (and specifically https://bugs.python.org/issue15263#msg164731) mentions this. -- components: IO messages: 302036 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failures on Windows in Python/traceback.c in case of a bad io.open type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31444] ResourceWarning in Python/traceback.c in case of a bad io.TextIOWrapper
New submission from Oren Milman: the following code causes a ResourceWarning: import io def _bad_TextIOWrapper(*args): return None io.TextIOWrapper = _bad_TextIOWrapper 1/0 this is because _Py_DisplaySourceLine() (in Python/traceback.c) assumes that io.TextIOWrapper() returned a stream object, and tries to call its close() method. in case calling close() fails, _Py_DisplaySourceLine() just calls PyErr_Clear(). maybe _Py_DisplaySourceLine() should try to call binary.close() in such cases? I also thought about adding a check such as: PyObject_IsInstance(fob, (PyObject*)&PyTextIOWrapper_Type); but I am not sure whether we should use PyTextIOWrapper_Type outside of the io module. -- components: IO messages: 302039 nosy: Oren Milman priority: normal severity: normal status: open title: ResourceWarning in Python/traceback.c in case of a bad io.TextIOWrapper type: resource usage versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31418] assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__
Oren Milman added the comment: what do you mean by 'Implicit converting to str can raise a warning or exception if __module__ is a bytes object.'? should we treat __module__ differently in case it is a bytes object? -- ___ Python tracker <https://bugs.python.org/issue31418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31418] assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__
Changes by Oren Milman : -- keywords: +patch pull_requests: +3534 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
New submission from Oren Milman: The following code causes an assertion failure on Windows: class BadEnv(dict): keys = None import subprocess import sys subprocess.Popen([sys.executable, "-c", "pass"], env=BadEnv()) this is because getenvironment() (in Modules/_winapi.c) calls PyMapping_Values() immediately after calling PyMapping_Keys(). calling PyMapping_Values() ultimately leads to calling _PyObject_FastCallDict(), which does 'assert(!PyErr_Occurred());'. thus, in case of an error in PyMapping_Keys(), the assertion fails. -- components: Extension Modules messages: 302181 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in subprocess.Popen() in case the env arg has a bad keys() method type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Changes by Oren Milman : -- keywords: +patch pull_requests: +3570 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method
New submission from Oren Milman: The following code causes an assertion failure: class BadInt(int): def __abs__(self): return None import random random.seed(BadInt()) this is because random_seed() (in Modules/_randommodule.c) assumes that PyNumber_Absolute() returned an int, and so it passes it to _PyLong_NumBits(), which asserts it received an int. what should we do in such a case? should we raise an exception? (the docs don't mention abs() in case the seed is an int - https://docs.python.org/3.7/library/random.html#random.seed) -- components: Extension Modules messages: 302208 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in random.seed() in case the seed argument has a bad __abs__() method type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Oren Milman added the comment: in 2.7 getenvironment() is in PC/_subprocess.c, and it also calls PyMapping_Values() immediately after calling PyMapping_Keys(). however, _PyObject_FastCallDict() doesn't exist here. in case of an error in both PyMapping_Keys() and PyMapping_Values(), the error in PyMapping_Values() just overwrites the error in PyMapping_Keys(). but I haven't gone over all of the code that could be run as part of PyMapping_Values(), so I am not sure whether something could go wrong in case PyMapping_Keys() failed. -- ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method
Oren Milman added the comment: sure. but what about the TypeError message? should it complain about the return value of abs(seed)? (the docs of random.seed don't mention abs().) -- ___ Python tracker <https://bugs.python.org/issue31478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Oren Milman added the comment: OK. but there isn't an assertion failure to test in 2.7, so is adding a test still relevant? -- ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Changes by Oren Milman : -- pull_requests: +3586 ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method
Changes by Oren Milman : -- keywords: +patch pull_requests: +3587 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method
Oren Milman added the comment: i opened a PR that implements the first option, but of course I wouldn't mind if you decide another option is better. -- ___ Python tracker <https://bugs.python.org/issue31478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31486] calling a _json.Encoder object raises a SystemError in case obj.items() returned a tuple
New submission from Oren Milman:
the following code causes a SystemError:
import json.encoder
class BadDict(dict):
def items(self):
return ()
encoder = json.encoder.c_make_encoder(None, None, None, None, 'foo', 'bar',
True, None, None)
encoder(obj=BadDict({'spam': 42}), _current_indent_level=4)
this is because encoder_call() (in Modules/_json.c) passes the 'obj' argument
so that eventually encoder_listencode_dict() calls PyMapping_Items() on it.
encoder_listencode_dict() assumes that PyMapping_Items() returned a list, and
passes it to PyList_Sort().
ISTM that subclassing dict and implementing items() so that it returns a tuple
is not unrealistic.
maybe we should silently convert the tuple that PyMapping_Items() returned to a
list?
--
components: Extension Modules
messages: 302278
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: calling a _json.Encoder object raises a SystemError in case obj.items()
returned a tuple
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31486>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31490] assertion failure in ctypes in case an _anonymous_ attr appears outside _fields_
New submission from Oren Milman: The following code causes an assertion failure: import ctypes class BadStruct(ctypes.Structure): _fields_ = [] _anonymous_ = ['foo'] foo = None this is because MakeAnonFields() (in Modules/_ctypes/stgdict.c) goes over the names specified in _anonymous_, and looks each name up in the class by calling PyObject_GetAttr(). in case an attribute of such a name is found (i.e. PyObject_GetAttr() succeeded), MakeAnonFields() assumes that the attribute was created by MakeFields(), so it asserts the type of the attribute is PyCField_Type. however, PyObject_GetAttr() would succeed also in case it is a normal attribute specified by the user, but isn't specified in _fields_, as in the code above. in such a case, the type of the attribute is not PyCField_Type, and so the assertion fails. -- components: ctypes messages: 302331 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in ctypes in case an _anonymous_ attr appears outside _fields_ type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31490] assertion failure in ctypes in case an _anonymous_ attr appears outside _fields_
Changes by Oren Milman : -- keywords: +patch pull_requests: +3606 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31492] assertion failures in case a module has a bad __name__ attribute
New submission from Oren Milman: The following code causes an assertion failure: import os os.__name__ = None os.does_not_exist this is because module_getattro() (in Objects/moduleobject.c) assumes that __name__ is a string, and passes it to PyErr_Format(), which asserts it is a string. if we fixed that one (so that the code above would raise an AttributeError), the following code would still cause an assertion failure: import os os.__name__ = None from os import does_not_exist this is because import_from() (in Python/ceval.c) also assumes that __name__ is a string, and passes it to PyUnicode_FromFormat(), which asserts it is a string. BTW, while we are in module_getattro(): isn't the second call to PyErr_Clear() redundant? (Ethan, IIUC, you worked on this as part of #8297 some years ago..) -- components: Extension Modules messages: 302348 nosy: Oren Milman, ethan.furman priority: normal severity: normal status: open title: assertion failures in case a module has a bad __name__ attribute type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31492] assertion failures in case a module has a bad __name__ attribute
Changes by Oren Milman : -- components: +Interpreter Core -Extension Modules ___ Python tracker <https://bugs.python.org/issue31492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31492] assertion failures in case a module has a bad __name__ attribute
Changes by Oren Milman : -- keywords: +patch pull_requests: +3611 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31505] assertion failure in _json.make_encoder() in case of a bad encoder() argument
New submission from Oren Milman:
The following code causes an assertion failure:
import _json
def _bad_encoder(*args):
return None
enc = _json.make_encoder(None, None, _bad_encoder, None,
'foo', 'bar', None, None, None)
enc(obj='spam', _current_indent_level=4)
This is because encoder_new() (in Modules/_json.c) assumes that the received
encoder() argument is a function that returns a string, and stores it in the
new PyEncoderObject.
When encoder_encode_string() is called (by encoder_listencode_obj()), it
returns whatever the stored encoder() returned, assuming it returned a string.
Then, encoder_listencode_obj() passes this value to _steal_accumulate(), which
passes it to _PyAccu_Accumulate(), which asserts it is a string.
Similarly, the following code also causes an assertion failure (only the obj
argument is different):
import _json
def _bad_encoder(*args):
return None
enc = _json.make_encoder(None, None, _bad_encoder, None,
'foo', 'bar', None, None, None)
enc(obj={'spam': 42}, _current_indent_level=4)
In this case, encoder_listencode_dict() passes whatever encoder_encode_string()
returned, to _PyAccu_Accumulate(), which asserts it is a string.
--
components: Extension Modules
messages: 302428
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: assertion failure in _json.make_encoder() in case of a bad encoder()
argument
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31505>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31505] assertion failure in json, in case _json.make_encoder() received a bad encoder() argument
Changes by Oren Milman : -- title: assertion failure in _json.make_encoder() in case of a bad encoder() argument -> assertion failure in json, in case _json.make_encoder() received a bad encoder() argument ___ Python tracker <https://bugs.python.org/issue31505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31505] assertion failure in json, in case _json.make_encoder() received a bad encoder() argument
Changes by Oren Milman : -- keywords: +patch pull_requests: +3638 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31531] crash and SystemError in case of a bad zipimport._zip_directory_cache
New submission from Oren Milman:
The following code causes the interpreter to crash (in case 'foo.zip' exists):
import zipimport
zipimport._zip_directory_cache['foo.zip'] = None
importer = zipimport.zipimporter('foo.zip')
importer.find_loader('bar')
This is because zipimport_zipimporter___init___impl() (in Modules/zipimport.c)
looks for the zipfile in _zip_directory_cache, and in case it is found, stores
its item in the new ZipImporter. Later, check_is_directory() assumes the stored
item is a dictionary, and passes it to PyDict_Contains(), which crashes.
Similarly, the following code causes a 'SystemError: new style getargs format
but argument is not a tuple':
import zipimport
importer = zipimport.zipimporter('foo.zip')
zipimport._zip_directory_cache['foo.zip']['foo\\__init__.py'] = None
importer.load_module('foo')
The same would happen if we replace the last line with
"importer.get_data('foo\\__init__.py')" or "importer.get_source('foo')".
This is because various parts of the code assume that the zipfile's item in
_zip_directory_cache is a dictionary, and that the module's item in this
dictionary is a tuple, which is eventually passed to get_data(), which passes
it to PyArg_ParseTuple(), which raises the SystemError.
Actually, I should have found this as part of #28261. ISTM that the fix for
this issue can easily also fix the issue described in #28261, by checking in
get_data() whether toc_entry is an 8-tuple.
Also, PyDict_GetItem() suppresses all errors, so in some places, e.g. in
get_module_info(), a bad _zip_directory_cache would probably just be ignored.
But ISTM that we should raise an error saying 'invalid _zip_directory_cache'
in any place where _zip_directory_cache is accessed (in case it is invalid).
What do you think?
--
components: Extension Modules
messages: 302612
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crash and SystemError in case of a bad zipimport._zip_directory_cache
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31531>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29720] potential silent truncation in PyLong_AsVoidPtr
New submission from Oren Milman: I am not sure whether such a platform exists, but on a platform where SIZEOF_VOID_P < SIZEOF_LONG, PyLong_AsVoidPtr (which is in Objects/longobject.c) is: long x; if (PyLong_Check(vv) && _PyLong_Sign(vv) < 0) x = PyLong_AsLong(vv); else x = PyLong_AsUnsignedLong(vv); if (x == -1 && PyErr_Occurred()) return NULL; return (void *)x; Thus, for example, 'PyLong_AsVoidPtr(PyLong_FromUnsignedLong(ULONG_MAX))' would silently truncate ULONG_MAX, and return without an error. An easy fix would be (mainly) to add to PyLong_AsVoidPtr 'Py_BUILD_ASSERT(SIZEOF_LONG <= SIZEOF_VOID_P);', but I am not sure we can make that assumption. Note that a compile time error is already raised: - by Objects/longobject.h, in case SIZEOF_VOID_P is different from SIZEOF_INT, SIZEOF_LONG and SIZEOF_LONG_LONG - by Modules/_multiprocessing/multiprocessing.h, in case SIZEOF_VOID_P is different from SIZEOF_LONG and SIZEOF_LONG_LONG -- components: Interpreter Core messages: 288984 nosy: Oren Milman priority: normal severity: normal status: open title: potential silent truncation in PyLong_AsVoidPtr type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29730] unoptimal calls to PyNumber_Check
New submission from Oren Milman:
current state
if (PyNumber_Check(obj)) {
someVar = PyNumber_AsSsize_t(obj, SomeError);
if (someVar == -1 && PyErr_Occurred()) {
return errVal;
}
}
else {
PyErr_Format(PyExc_TypeError,
"integer argument expected, got '%.200s'",
Py_TYPE(obj)->tp_name);
return errVal;
}
Something similar to this happens in:
- Modules/mmapmodule.c in mmap_convert_ssize_t
- Modules/_io/_iomodule.c in _PyIO_ConvertSsize_t
- Modules/_io/stringio.c in:
* _io_StringIO_read_impl
* _io_StringIO_readline_impl
* _io_StringIO_truncate_impl
(Moreover, in:
- Objects/bytes_methods.c in parse_args_finds_byte
- Objects/exceptions.c in oserror_init
PyNumber_AsSsize_t is called only if PyNumber_Check returns true.)
Note that:
- PyNumber_Check checks whether nb_int != NULL or nb_float != NULL.
- PyNumber_AsSsize_t calls PyNumber_Index, which, before calling
nb_index, raises a TypeError (with a similar error message) in case
nb_index == NULL.
- The docs say '... when __index__() is defined __int__() should also be
defined ...'.
So the behavior with and without the call to PyNumber_Check is quite the same.
The only potential advantage of calling PyNumber_Check is skipping the call to
PyNumber_AsSsize_t.
But PyNumber_AsSsize_t would be called also in case
nb_index == NULL and (nb_int != NULL or nb_float != NULL).
Thus, the only case in which the call to PyNumber_Check might be useful, is
when nb_int == nb_float == nb_index == NULL.
proposed changes
Either remove each of these calls to PyNumber_Check, or at least replace it
with a call to PyIndex_Check, which checks whether nb_index != NULL, and thus
would be more useful than PyNumber_Check.
Note that such a change shouldn't affect the behavior, except for a slightly
different wording of the error message in case a TypeError is raised.
------
components: IO
messages: 289048
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: unoptimal calls to PyNumber_Check
type: enhancement
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue29730>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do
New submission from Oren Milman:
current state
import io
class IntLike():
def __init__(self, num):
self._num = num
def __index__(self):
return self._num
__int__ = __index__
io.StringIO('blah blah').read(IntLike(2))
io.StringIO('blah blah').readline(IntLike(2))
io.StringIO('blah blah').truncate(IntLike(2))
io.BytesIO(b'blah blah').read(IntLike(2))
io.BytesIO(b'blah blah').readline(IntLike(2))
io.BytesIO(b'blah blah').truncate(IntLike(2))
The three StringIO methods are called without any error, but each of the three
BytesIO methods raises a "TypeError: integer argument expected, got 'IntLike'".
This is because the functions which implement the StringIO methods (in
Modules/_io/stringio.c):
- _io_StringIO_read_impl
- _io_StringIO_readline_impl
- _io_StringIO_truncate_impl
use PyNumber_AsSsize_t, which might call nb_index.
However, the functions which implement the BytesIO methods (in
Modules/_io/bytesio.c):
- _io_BytesIO_read_impl
- _io_BytesIO_readline_impl
- _io_BytesIO_truncate_impl
use PyLong_AsSsize_t, which accepts only Python ints (or objects whose type is
a subclass of int).
proposed changes
- change those BytesIO methods so that they would accept integer types (i.e.
classes that define __index__), mainly by replacing PyLong_AsSsize_t with
PyNumber_AsSsize_t
- add tests to Lib/test/test_memoryio.py to verify that all six aforementioned
methods accept integer types
--
components: IO
messages: 289136
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: BytesIO methods don't accept integer types, while StringIO counterparts
do
type: behavior
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue29741>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do
Oren Milman added the comment: I don't have a use case for that. (I noticed this behavior by chance, while working on some other issue.) However, IIUC, commit 4fa88fa0ba35e25ad9be66ebbdaba9aca553dc8b, by Benjamin Peterson, Antoine Pitrou and Amaury Forgeot d'Arc, includes patching the aforementioned StringIO functions, so that they would accept integer types. So I add them to the nosy list, as I guess that the use cases for accepting integer types in StringIO methods are also use cases for accepting integer types in BytesIO. And now that you mention the docs, according to them, both StringIO and BytesIO inherit these methods from BufferedIOBase or IOBase. Thus, the methods are already expected to behave the same, aren't they? -- nosy: +amaury.forgeotdarc, benjamin.peterson, pitrou ___ Python tracker <http://bugs.python.org/issue29741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do
Oren Milman added the comment: using _PyIO_ConvertSsize_t sounds great. with regard to tests for accepting integer types in other classes, there aren't a lot of them, so I guess it is not always tested. still, it is tested in (excluding tests of the actual feature of treating integer types as ints): test_bytes, test_cmath, test_int, test_math, test_range, test_re, test_slice, test_struct, test_unicode and test_weakref. -- ___ Python tracker <http://bugs.python.org/issue29741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do
Oren Milman added the comment: also with regard to adding tests, consider the following scenario: in the future, someone writes a patch for these functions, which makes them not accept integer types anymore. assuming the tests don't exist, the writer of the patch doesn't realize the patch broke something, and so the patch is committed. years later, when the patch is finally a part of the stable release, it breaks a lot of code out there. lastly, ISTM adding these tests would be quite simple anyway. -- ___ Python tracker <http://bugs.python.org/issue29741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do
Oren Milman added the comment: I wrote a patch, but I attach it here and not in a PR, as you haven't approved adding tests. (I would be happy to open a PR with or without the tests.) I ran the test module (on my Windows 10), and seems like the patch doesn't break anything. also, while running test_memoryio with my added tests, i noticed some places in Lib/_pyio.py which seemed like they should be changed. in particular, I changed 'var.__index__' to 'var = var.__index__()' in some places. I feel really uncomfortable about that change, as it undos a change committed by Florent Xicluna in b14930cd93e74cae3b7370262c6dcc7c28e0e712. Florent, what was the reason for that change? -- keywords: +patch nosy: +flox Added file: http://bugs.python.org/file46709/patchDraft1.diff ___ Python tracker <http://bugs.python.org/issue29741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do
Oren Milman added the comment: should I open a PR (even though we didn't give Florent enough time to respond)? -- ___ Python tracker <http://bugs.python.org/issue29741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
