Armin Rigo added the comment:
(B4) if you have a stack of generators where each is in 'yield from' from
the next one, and you call '.next()' on the outermost, then it enters
and leaves all intermediate frames. This is costly but may be
required to get the sys.settrace(
Armin Rigo added the comment:
(B1) on modern Linux: if the first call in the process to
socketpair() ends in a EINVAL, then cpython will (possibly wrongly)
assume it was caused by SOCK_CLOEXEC and not use SOCK_CLOEXEC at all
in the future
Armin Rigo added the comment:
(B3) re.sub(b'y', bytearray(b'a'), bytearray(b'xyz')) -> b'xaz'
re.sub(b'y', bytearray(b'\\n'), bytearray(b'xyz')) -> internal TypeError
--
__
Armin Rigo added the comment:
(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
to a refcount crash. It does this::
old_mro = type->tp_mro;
...mro_invoke()... /* might cause reentrance */
type->tp_mro = new_mro;
...
Py_XDEC
Armin Rigo added the comment:
(C5) setting f_lineno didn't evolve when the rest of the bytecodes evolved,
which means it is not safe any more::
import sys
def f():
try:
raise ValueError# line 5
except ValueError:
print(42) #
New submission from Armin Rigo:
As discussed on python-dev, I am creating omnibus issues from the lists of
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues
that I found while developing Python 3.5.2 support for PyPy. These occur with
CPython 3.5.2 but most of
Armin Rigo added the comment:
(C4) faulthandler: register(): the signal handler, faulthandler_user(),
changes errno in faulthandler_dump_traceback() but fails to restore it
if chain=False. This can rarely cause random nonsense in the main
program
New submission from Armin Rigo:
As discussed on python-dev, I am creating omnibus issues from the lists of
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues
that I found while developing Python 3.5.2 support for PyPy. These occur with
CPython 3.5.2 but most of
Armin Rigo added the comment:
(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
to a refcount crash. It does this::
old_mro = type->tp_mro;
...mro_invoke()... /* might cause reentrance */
type->tp_mro = new_mro;
...
Py_XDEC
Armin Rigo added the comment:
(C3) _PyGen_yf() checks the opcode at [f_lasti + 1], which is the next
opcode that will run when we resume the generator: either it is the
opcode following the YIELD, or it is exactly YIELD_FROM. It is not
possible at the moment to write Python code that
Armin Rigo added the comment:
(C2) os.scandir() direntry objects should not have stat() called from two
threads concurrently. It will make two stat objects and leak one of
them.
--
___
Python tracker
<http://bugs.python.org/issue28
Armin Rigo added the comment:
os.scandir() returns an iterable object that should not be used
from multiple threads. Doing so can e.g. cause one thread to
close the dirp while another thread is still using it. This is
likely to crash. Similarly, the test for (!iterator->dirp) at
Armin Rigo added the comment:
Agreed about fixing the other issues. I'm still unclear that we need anything
more than just the _remove_dead_weakref function to do that, but also, I don't
see a particular problem with adding self._commit_removals() a bit everywhere.
About the O(1) e
Armin Rigo added the comment:
I think the issue of __len__() is a different matter. More below.
>> The C function would simply call PyObject_GetItem() and
>> PyObject_DelItem()---without releasing the GIL in the middle.
>
> If you implement it like that, and the dictiona
Armin Rigo added the comment:
issue28427-atomic.patch: is it still necessary to modify weakref.py so much,
then?
What I had in mind was a C function with Python signature "del_if_equal(dict,
key, value)"; the C function doesn't need to know about weakrefs and checking
if they
Armin Rigo added the comment:
Looks ok now!
--
___
Python tracker
<http://bugs.python.org/issue11145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
I reviewed your patch again. It does look good after all: I find only one
issue---it seems I implied there were several ones but I can't find more. The
issue is that PyString_AsString(result) will succeed if 'result' is a unicode.
New submission from Armin Rigo:
``python3.5 --help`` gives this information:
-u : unbuffered binary stdout and stderr, stdin always buffered
However, stdout and stderr are actually always opened in text mode, and print()
always expects a string and never a bytes object. This usage of
Armin Rigo added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue19542>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Armin Rigo added the comment:
I'll admit I don't know how to properly fix this issue. What I came up with so
far would need an atomic compare_and_delete operation on the dictionary
self.data, so that we can do atomically:
+elif self.data[wr.
New submission from Armin Rigo:
Follow-up on http://bugs.python.org/issue19542.
Another crash of using WeakValueDictionary() in a thread-local fashion inside a
multi-threaded program. I must admit I'm not exactly sure why this occurs, but
it is definitely showing an issue: two th
Armin Rigo added the comment:
You're welcome. Unrelated, but I'm collecting similar issues in a file at
http://bitbucket.org/pypy/extradoc/raw/extradoc/planning/py3.5/cpython-crashers.rst
. After reporting the first two, I stopped, and will report them all in bulk
some time late
Armin Rigo added the comment:
For completeness:
* the crasher I attached gets a bus error even before calling
ffi_closure_free(). At that point, only ffi_closure_alloc() has been
called---in both parent and child.
* stricly speaking, cffi is not fixed: it has the same problem when
using
Changes by Armin Rigo :
--
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python
3.6
___
Python tracker
<http://bugs.python.org/issue25
Armin Rigo added the comment:
Attached trivial example. This gives for me a bus error when run with selinux
(actually tested by changing the "return 0;" to "return 1;" in
selinux_enabled_check() file Modules/_ctypes/libffi/src/closures.c).
If you comment out any of the
New submission from Armin Rigo:
PyFrameObject.f_gen is a pointer (not a reference) to a generator/coroutine
object. But the latter doesn't always correctly clean it up when it dies.
This pointer is used by frame.clear().
Here is an example I made, which ends in a segfault. This ex
New submission from Armin Rigo:
_PyGen_Finalize() should not fail with an exception. Doing so can cause
various SystemErrors or even fatal errors. For example, run this with "python
-Werror":
import gc
async def f():
pass
f()
gc.collect() # RuntimeWarning
Armin Rigo added the comment:
...ah, upon closer inspection, we don't use the ``interact()`` method anyway.
We already copied and tweaked this method: one problem was that it gives no way
to run without printing at least one '\n' of banner at the beginning. Then a
more impo
Armin Rigo added the comment:
I'm fine with `exitmsg`. I guess it would be a flag (not `None` as you wrote),
defaulting to `True`?
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
Can we make the exit message optional? Otherwise PyPy will need to patch
code.py to add the option to not display this message when used as the normal
REPL (yes, PyPy uses the plain code.py as its built-in REPL).
--
nosy: +arigo
Armin Rigo added the comment:
Uh, you're right. Then I can also add that putwch() strangely checks for
unicode strings of length != 0 instead of == 1, despite what it says it its
error message. These functions appear not to be tested or even (in case of
ungetwch()) used by a
New submission from Armin Rigo:
In Python 2.7, PC/msvcrtmodule.c, the function msvcrt_ungetwch() calls
_ungetch() instead of _ungetwch() as was probably intended.
--
components: Extension Modules
messages: 270620
nosy: arigo
priority: normal
severity: normal
status: open
title
Armin Rigo added the comment:
See also
https://bitbucket.org/pypy/pypy/issues/2289/incorrect-unicode-normalization .
It seems that you reached the same conclusion than the OP in that issue: the
problem would really be that normalizing "\uafb8\u11a7" should not drop the
second
Armin Rigo added the comment:
Note: the examples can also be written in this clearer way on Python 3:
>>> from unicodedata import normalize
>>> print(ascii(normalize("NFC", "---\uafb8\u11a7---")))
'---\uafb8\u11a7---'
>>> p
New submission from Armin Rigo:
There is an apparent inconsistency in unicodedata.normalize("NFC"), introduced
with the switch from the Unicode DB 5.1.0 to 5.2.0 (in Python 2.7). First,
please note that my knowledge of unicode is limited, so I may be wrong and the
following behavio
Armin Rigo added the comment:
That's what I suggested ("compile.c:compiler_addop(): special-case code objects
too, and stick their identity in the tuple 't'.") and how I fixed the same bug
in PyPy (https://bitbucket.org/pypy/
Armin Rigo added the comment:
Other possible minimal fixes:
* compile.c:compiler_addop(): special-case code objects too, and stick their
identity in the tuple 't'.
* or, in compile.c:makecode(), append the first row number to
Armin Rigo added the comment:
(Typo: "only 45% faster" should be "only 45% of the time")
--
___
Python tracker
<http://bugs.python.org/issue25823>
___
_
Armin Rigo added the comment:
Fwiw, I made a trivial benchmark in C that loads aligned and misaligned shorts
( http://paste.pound-python.org/show/HwnbCI3Pqsj8bx25Yfwp/ ). It shows that
the memcpy() version takes only 65% of the time taken by the two-bytes-loaded
version on a 2010 laptop. It
Armin Rigo added the comment:
Actually, Py_DECREF() may also release the GIL by calling a Python __del__()
method; it doesn't have to directly decref the exact object.
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
PyWeakref_GET_OBJECT() is inherently dangerous: the weakref might go away not
only the next time the GIL is released, but also the next time the code does
any seemingly unrelated Py_DECREF() (which might decref the object into
inexistence) or memory allocation
Armin Rigo added the comment:
This is a known general issue which is documented in
Lib/test/crashers/borrowed_ref_1 inside the 2.7 branch. In trunk, I see that
this file has been deleted, although the issue has not been solved in general.
Only the particular crash in the file has been
Armin Rigo added the comment:
Ok, then with pickle you can have the same problem but only with
None-vs-no-total. Here is an artificial example:
import itertools, pickle
def foo(a, b):
print(a, b)
a = itertools.accumulate([3, 4, 5], foo)
next(a)
next(a) # prints: 3, 4
b = pickle.loads
New submission from Armin Rigo:
itertools.accumulate() has got methods __reduce__() and __setstate__() which
fail at saving/restoring the state in all cases. Example:
>>> a = itertools.accumulate([0.0, 42])
>>> next(a)
0.0
>>> b = copy.deepcop
New submission from Armin Rigo:
Ctypes uses libffi's `ffi_closure_alloc()`, which has a bug that make existing
applications obscurely crash in one situation: if we are running on SELinux,
making use of callbacks, and forking. This is because `ffi_closure_alloc()`
will detect that
Armin Rigo added the comment:
Roman: bz2.decompress(comp.read()) returns a string, so you can't use "with" on
it. This bug was about using "with bz2.BZ2File(...) as f:".
--
___
Python tracker
<http
Armin Rigo added the comment:
Patch LGTM too. Optionally a test is needed for each of the other cases in it
too, but please don't cause that comment to stop it from getting in.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue24806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
To be clearer, this bug report is, more precisely, about subclassing built-in
classes that are not meant to be subclassable. This includes type(None) and
bool.
--
___
Python tracker
<http://bugs.python.org/issue24
Armin Rigo added the comment:
@brechtm No, the example you give is wrong. It is correct that this refuses to
work (and unrelated to this bug):
class Integer(object, int): pass
for reasons explained in the docs.
--
___
Python tracker
<h
Armin Rigo added the comment:
FWIW ``bool(Null())`` gives "correctly" the result False in CPython 3.5.
The problem in my opinion is that "!Py_TPFLAGS_BASETYPE" is checked only on the
best base instead of on all bases. It lets this kind of nonsense pass through.
In CPyt
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
Also, if we want to be paranoid, the _PyObject_GetAttrId() can return anything,
not necessarily a string object. This would make the following
PyUnicode_FromFormat() fail. So maybe you also want to overwrite failures in
PyUnicode_FromFormat() with the final
Armin Rigo added the comment:
I'd guess so: if the PyObject_GetAttrId() fails, then ignore the rest of the
code that was added in https://hg.python.org/cpython/rev/fded07a2d616 and jump
straight to ``PyErr_Format(PyExc_Import
Changes by Armin Rigo :
Added file: http://bugs.python.org/file39791/test_case.py
___
Python tracker
<http://bugs.python.org/issue24492>
___
___
Python-bugs-list mailin
New submission from Armin Rigo:
A regression in 3.5: if we use custom objects as modules (like some projects
do), then these custom objects may not have an attribute called "__name__".
There is new code in 3.5 added for issue #17636 which tries sometimes to read
the "__name
Armin Rigo added the comment:
Related to http://bugs.python.org/issue19979 and others mentioned there.
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue24
Armin Rigo added the comment:
No problem from PyPy.
--
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue24340>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Armin Rigo:
The computation of `co_stacksize' by the compiler is known to give only an
upper bound estimate. http://bugs.python.org/issue1754094 is an example of
fixing a "leak" where every repetition of a statement makes `co_stacksize'
bigger by 1. H
Armin Rigo added the comment:
The PyArg_ParseTuple() size arguments should be of type "Py_ssize_t" instead of
"int".
--
nosy: +arigo
___
Python tracker
<http://bug
Armin Rigo added the comment:
Ah, thanks, I missed there was already an issue.
The patch's logic is as follows: when pressing tab anywhere in the line, if the
word to complete is empty (which might be for any number of reasons, like the
cursor is after another space or a non-word char
New submission from Armin Rigo:
In the interactive prompt:
>>> if 1:
...
Pressing tab here should just insert 4 spaces. It makes no sense to display all
500 possible "completions" of the empty word, and using tab to indent is a very
common feature of any editor with a
Armin Rigo added the comment:
Converted the test into an official test, which fails; and wrote the patch for
CPython "3.trunk" and for CPython 2.7. Please review and commit.
--
keywords: +needs review -patch
stage: needs patch ->
Changes by Armin Rigo :
Added file: http://bugs.python.org/file37993/fix-weakvaluedict-2.7.diff
___
Python tracker
<http://bugs.python.org/issue19542>
___
___
Python-bug
Changes by Armin Rigo :
--
keywords: +patch
Added file: http://bugs.python.org/file37992/fix-weakvaluedict.diff
___
Python tracker
<http://bugs.python.org/issue19
Armin Rigo added the comment:
Sorry, your patch still contains similar issues. I postponed continuing to
bounce it back and forth, but it seems that someone else needs to take my place
now.
--
___
Python tracker
<http://bugs.python.org/issue11
New submission from Armin Rigo:
It's not possible to write a settrace() or setprofile() function that remains
active if we're about to run out of stack. If we are, we get a RuntimeError
when the function is called. The RuntimeError is normally propagated, but in
case it is eaten
Changes by Armin Rigo :
--
keywords: +patch
Added file: http://bugs.python.org/file37359/pyio.diff
___
Python tracker
<http://bugs.python.org/issue17852>
___
___
Armin Rigo added the comment:
Here is a proof-of-concept. It changes both _pyio.py and bufferedio.c and was
tested with the examples here. (See what I meant with "linked lists".) The
change in textio.c is still missing, but should be very similar to
bufferedio.c. This is simi
Armin Rigo added the comment:
Antoine: I'm trying to explain what in the three lines that follow the parts
you quoted. I already tried to explain it a few times above. Now I feel that
I'm not going anywhere, so I'll quote back myself from 2013-04-27: "Feel free
to close
Armin Rigo added the comment:
Antoine: sorry if I wasn't clear enough. Obviously you want to encourage
people to close their files, but I think personally that it is very bad for the
implementation to *most of the time* work anyway and only rarely fail to flush
the files. So, speaking
Armin Rigo added the comment:
Maybe accepting the fact that relying on finalizers is a bad idea here?
--
___
Python tracker
<http://bugs.python.org/issue17
Armin Rigo added the comment:
To add to the confusion: Antoine's example produces an empty file on the
current trunk cd282dd0cfe8. When I first tried it on a slightly older trunk
(157 changesets ago), it correctly emitted a file with "barXXX ", but only if
"gc.co
Armin Rigo added the comment:
(Ah, it's probably a reference from the trace function -> func_globals -> f).
--
___
Python tracker
<http://bugs.python.
Armin Rigo added the comment:
If I understood correctly, Python 3.4 tries harder to find cycles and call
destructors at the end of the program, but that's not a full guarantee. For
example you can have a reference from a random C extension module.
While trying to come up with an examp
Armin Rigo added the comment:
I hate to repeat myself, but if the C standard says "files are flushed at
exit"; if Python 2 follows this standard; and if Python 3 follows it most of
the time but *not always*... then it seems to me that something is very, very
buggy in the worst po
Armin Rigo added the comment:
Victor: there is the GIL, you don't need any locking.
--
___
Python tracker
<http://bugs.python.org/issue17852>
___
___
Pytho
Armin Rigo added the comment:
If buf contains "-00" and the type is 'o', then it will be modified in-place
even if the string is shared.
--
___
Python tracker
<http://bug
Armin Rigo added the comment:
Ah, sorry. Ok. Now a different issue: the user-defined function can return an
interned string. If it has a refcount of 1, _PyString_FormatLong() will mutate
it. Then when we DECREF it, string_dealloc() will not find it any more in the
interned dict and crash
Armin Rigo added the comment:
+if (Py_REFCNT(result) == 1)
+buf[len] = '\0';
...and if the refcount is not equal to 1, then too bad, we won't null-terminate
the string and hope that nobody crashes
Armin Rigo added the comment:
It's seriously obscure to call a user-defined __oct__ method and then mangle
the resulting string in ways that only make sense if the __oct__ method
returned something reasonable.
The patch is probably a little more complicated than it could be. For exampl
Armin Rigo added the comment:
In my own case I use os.popen("wget ...") instead of urllib2 just because some
version long ago failed on some web site. I can trust that this external tool
works all the time. It would be great if urllib2 worked as well nowadays.
So my opinion on
New submission from Armin Rigo:
$ LINES=20 python Lib/test/test_pydoc.py
...
File ".../Lib/pydoc.py", line 1448, in ttypager
r = inc = os.environ.get('LINES', 25) - 1
TypeError: unsupported operand type(s) for -: 'str' and 'int'
duh.
--
co
Armin Rigo added the comment:
For completeness:
Python 2.7.6: ntpath.splitdrive('//') => ('', '//')
Python 2.7.8: ntpath.splitdrive('//') => IndexError
--
___
Pyth
New submission from Armin Rigo:
Calling Python 2.7's new version of ntpath.splitdrive() with argument either
'//' or r'\\' results in an IndexError: string index out of range.
--
messages: 226163
nosy: arigo
priority: normal
severity: normal
status: open
Armin Rigo added the comment:
It was clear to me four years ago. Now I'd have to dig again as much as you do.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Armin Rigo:
The documentation of the built-in compile() function is not 100% clear but I
think it says that giving the "optimize=1" argument turns "__debug__" to false
in the compiled code (
https://docs.python.org/3.5/library/functions.html?highl
Armin Rigo added the comment:
...but I don't think PyPy should be by itself a good enough reason to reject
this patch. It would be fine if timeit detects which interpreter it runs on,
and only tries to unroll on CPython, for example.
--
___
P
Armin Rigo added the comment:
The opposite argument might be relevant too: in some cases, a tracing JIT
compiler seeing a long block of code might perform artificially worse. If each
repeated line creates a branching path with two outcomes of roughly equal
likeliness, then if the line is
Changes by Armin Rigo :
--
resolution: -> not a bug
___
Python tracker
<http://bugs.python.org/issue21778>
___
___
Python-bugs-list mailing list
Unsubscrib
Armin Rigo added the comment:
Ah! Thanks. I systematically missed the "flags" arguments passed in the
getbufferproc function.
(I thought I had to tell PyBuffer_FillInfo() what kind of format we actually
provide, but it seems that the interface is the other way around. I don&#x
Changes by Armin Rigo :
Added file: http://bugs.python.org/file35655/xymodule.c
___
Python tracker
<http://bugs.python.org/issue21778>
___
___
Python-bugs-list mailin
New submission from Armin Rigo:
Following the documentation at https://docs.python.org/3/c-api/buffer.html, if
we write a custom object in C with a getbufferproc that simply returns
PyBuffer_FillInfo(...), then it works fine up to Python 3.2 but segfaults in
Python 3.3 depending on what we do
Armin Rigo added the comment:
Terry: I meant exactly what I wrote, and not some unrelated examples:
def f():
n = 1
class A: n = n
doesn't work, but the same two lines ("n = 1"; "class A: n = n") work if
written at module level
New submission from Armin Rigo:
The docs still say that the default __hash__() is equal to id(), but that's not
the case since Python 2.7.
--
assignee: docs@python
components: Documentation
files: lang-ref-fix.diff
keywords: patch
messages: 215517
nosy: arigo, docs@python
pri
Changes by Armin Rigo :
--
assignee: arigo ->
___
Python tracker
<http://bugs.python.org/issue1617161>
___
___
Python-bugs-list mailing list
Unsubscrib
Armin Rigo added the comment:
CPython 2.7 is in feature-freeze, so we need to add it to __pypy__. If people
here decide to add it more officially to CPython 3.x, then we'll also add it
into pypy3, obviously. I'm sure a debugger can cope with a few extra ifs to
check on which plat
Armin Rigo added the comment:
Sorry to hijack CPython's bug tracker for that, but can you check if this makes
sense to you? I added a function 'locals_to_fast()' to the __pypy__ built-in
module which just calls the PyPy equivalent to PyFrame_LocalsToFast(). Your
tests ar
Armin Rigo added the comment:
Also, can you provide a concrete case? Trying around in CPython 2.7, it seems
that locals of the current frame can always be modified from a pdb.set_trace().
--
___
Python tracker
<http://bugs.python.org/issue1654
101 - 200 of 384 matches
Mail list logo
