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()/setprofile() hooks
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
--
___
Python tracker <rep...@bugs.python.org>
<http://
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_XDECREF(o
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) # line
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
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
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_XDECREF(o
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
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 <rep...@bugs.python.org>
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->d
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) expectation
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 the
Armin Rigo added the comment:
Looks ok now!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11145>
___
___
Python-bugs-list
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.
Then you call
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
Armin Rigo added the comment:
ping
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19542>
___
___
Python-bugs-list mailing list
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.key] is 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 threads
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 later, but you
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 <ar...@users.sourceforge.net>:
--
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python
3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 example
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() # Runt
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 important tweak
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 anyone
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---'
>>> print(ascii
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 beha
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/pypy/commits/7e
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 co_consts
Armin Rigo added the comment:
(Typo: "only 45% faster" should be "only 45% of the time")
--
___
Python tracker <rep...@bugs.python.org>
<http
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
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
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
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 rep...@bugs.python.org
http://bugs.python.org
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24806
___
___
Python-bugs-list
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 rep...@bugs.python.org
http
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 rep
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 CPython 2.7 (but not 3.5
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_ImportError
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24450
___
___
Python-bugs-list
Changes by Armin Rigo ar...@users.sourceforge.net:
Added file: http://bugs.python.org/file39791/test_case.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24492
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__ of a module when
Armin Rigo added the comment:
Related to http://bugs.python.org/issue19979 and others mentioned there.
--
nosy: +arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
Armin Rigo added the comment:
No problem from PyPy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24450
___
___
Python-bugs-list mailing list
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24340
___
___
Python-bugs-list
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. However, in the whole 3
Armin Rigo added the comment:
The PyArg_ParseTuple() size arguments should be of type Py_ssize_t instead of
int.
--
nosy: +arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23830
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 character
New submission from Armin Rigo:
In the interactive prompt:
if 1:
... press tab here
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 Python mode
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 - patch review
Changes by Armin Rigo ar...@users.sourceforge.net:
Added file: http://bugs.python.org/file37993/fix-weakvaluedict-2.7.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19542
Changes by Armin Rigo ar...@users.sourceforge.net:
--
keywords: +patch
Added file: http://bugs.python.org/file37992/fix-weakvaluedict.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19542
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 rep...@bugs.python.org
http
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 (e.g. see
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 possible way
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 example, I
Armin Rigo added the comment:
(Ah, it's probably a reference from the trace function - func_globals - f).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17852
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.collect() was present. Without
Armin Rigo added the comment:
Maybe accepting the fact that relying on finalizers is a bad idea here?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17852
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 only
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 anyway as not-a-bug
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 similar
Changes by Armin Rigo ar...@users.sourceforge.net:
--
keywords: +patch
Added file: http://bugs.python.org/file37359/pyio.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17852
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 rep...@bugs.python.org
http://bugs.python.org/issue11145
Armin Rigo added the comment:
Victor: there is the GIL, you don't need any locking.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17852
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 example,
I
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 because
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:
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 this issue
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
title: ntpath.splitdrive
Armin Rigo added the comment:
For completeness:
Python 2.7.6: ntpath.splitdrive('//') = ('', '//')
Python 2.7.8: ntpath.splitdrive('//') = IndexError
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22312
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.
--
components: Library (Lib)
messages: 226177
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 rep...@bugs.python.org
http://bugs.python.org/issue9134
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?highlight=compile#compile
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
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.
--
___
Python
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
Changes by Armin Rigo ar...@users.sourceforge.net:
Added file: http://bugs.python.org/file35655/xymodule.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21778
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't see
how I would
Changes by Armin Rigo ar...@users.sourceforge.net:
--
resolution: - not a bug
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21778
___
___
Python
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 instead of in a function
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
priority
Changes by Armin Rigo ar...@users.sourceforge.net:
--
assignee: arigo -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1617161
___
___
Python-bugs
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 are passing, so I
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 platform
Armin Rigo added the comment:
Hi Fabio! This is admittedly a corner-case use case, but if you think it would
be worth it, we can very easily add this as a feature to PyPy (by making
frame.f_locals writeable). Then we can add the write inside pdb, and you could
do the same for PyDev when
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 rep...@bugs.python.org
http
Armin Rigo added the comment:
Instances of 'staticmethod' or 'classmethod' are not callable. I'm unsure why
not, but it's good enough, as you need to go through various unexpected hops in
order to try to call one.
'dict.fromkeys' is not a classmethod, as seen by dict.__dict__['fromkeys
Armin Rigo added the comment:
PyPy 2.x accepts null characters in all of import, exec and eval, and complains
if they occur in non-comment.
PyPy 3.x refuses them in import, which is where this bug report originally
comes from (someone complained that CPython 3.x accepts them but not PyPy
3.x
Armin Rigo added the comment:
Fwiw, both exec and eval() ban NUL bytes, which means that there is a strange
case in which some files can be imported, but not loaded and exec'ed. So I
agree with Benjamin.
--
___
Python tracker rep
101 - 200 of 375 matches
Mail list logo
