New submission from Jiří Kučera sanc...@gmail.com:
Invoking the `close' method of `_io.BufferedWriter' instance created by
`open(0,wb)' command cause the Python interpreter crash.
Python interpreter info:
mode: interactive
version info: Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
components: +IO
nosy: +benjamin.peterson, ezio.melotti, pitrou, stutzbach
stage: - test needed
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12969
Stefan Krah stefan-use...@bytereef.org added the comment:
The failure was introduced by issue #12655. I attach a minimal script
to reproduce the segfault.
--
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file23138/crash.py
___
Python
Stefan Krah stefan-use...@bytereef.org added the comment:
And here's a full backtrace of crash.py:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400225f0 (LWP 633)]
0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
(gdb) bt
#0 0x40011d20 in __tls_get_addr
Stefan Krah stefan-use...@bytereef.org added the comment:
https://bugzilla.redhat.com/show_bug.cgi?id=726536 claims that the
glibc issue (which is relevant for skipping the test case) is fixed
in glibc-2.14.90-8.
I suspect the only way of running the test case reliably is whitelisting
a couple
Changes by Mark Dickinson dicki...@gmail.com:
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Yes, please let's not add any new __int__-based duck typing here; IMO, we
should be moving away from such uses of __int__. I'd be fine with __index__
based duck-typing.
--
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
I don't think it is practical to support both ABIs.
I suspect you're right.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7201
___
Jesús Cea Avión j...@jcea.es added the comment:
Under Python 3, open(integer) tries to open a file descriptor.
So, f=open(0,...); f.close() closes stdin, rightly shutting down the
interpreter. It is not a crash, it is a shutdown. Tested under Linux.
The point is if opening a file descriptor
Jesús Cea Avión j...@jcea.es added the comment:
In help(open) I see this:
file is either a text or byte string giving the name (and the path
if the file isn't in the current working directory) of the file to
be opened or an integer file descriptor of the file to be
wrapped. (If
STINNER Victor victor.stin...@haypocalc.com added the comment:
The failure was introduced by issue #12655
Wow, great job!
crash.py looks like a libc and/or kernel bug. Can you try the glibc 2.14
(released the 2011-05-31)? You should first check if it is not a duplicate of
Éric Araujo mer...@netwok.org added the comment:
In addition, error handling/reporting is not trivial to get right. We’ve had
to fix the code in distutils2 and it’s still not quite right (#12703).
I opened this report because I’d like to see all stdlib modules use the same
functions and I’d
Éric Araujo mer...@netwok.org added the comment:
FTR, I tried checking sys.ps1 instead of argv but it’s the same problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5845
___
Éric Araujo mer...@netwok.org added the comment:
I have added tests to make sure the return value (depending on the local
parameter) is correct. Please test when you have a free slot. If it fails,
the usual line after the XXX comment should be deleted and the test re-run.
--
Added
Changes by Éric Araujo mer...@netwok.org:
Removed file: http://bugs.python.org/file22948/fix-list_distinfo_files.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12785
___
Changes by Éric Araujo mer...@netwok.org:
Removed file: http://bugs.python.org/file23065/fix-list_distinfo_files-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12785
___
Éric Araujo mer...@netwok.org added the comment:
When will it raise an AttributeError?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12967
___
Ezio Melotti ezio.melo...@gmail.com added the comment:
fd support is intentional, see Modules/_io/_iomodule.c:318
OTOH closing sys.stdin doesn't exit Python, so I'm not sure why closing fd 0
should.
I was also thinking about possible security implications of this, but if
someone tries to
New submission from Марк Коренберг socketp...@gmail.com:
Consider code:
for (root, dirs, nondirs) in os.walk(path, followlinks=False):
print (nondirs)
This code will not print symlinks that refer to some dir. I think it is the bug.
In other words: If followlinks is True, we should
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12970
___
___
sbt shibt...@gmail.com added the comment:
Here is a patch which adds the following functions:
forking_disable()
forking_enable()
forking_is_enabled()
set_semaphore_prefix()
get_semaphore_prefix()
To create child processes using fork+exec on Unix, call
forking_disable() at the
Марк Коренберг socketp...@gmail.com added the comment:
Also, there is some mis-optimisation for followlinks=False: stat() and then
lstat() will be called. Instead of one lstat().
Code may be rewritten as (but I don't know about cross-platform issues):
-
if
New submission from Марк Коренберг socketp...@gmail.com:
When skiplinks is False (by default), it should as in current implementation,
i.e. using stat().
if skiplinks is True, isidr() should use lstat() and same logick.
If one will be implemented, os.walk() should be patched (see issue12970)
Changes by Марк Коренберг socketp...@gmail.com:
--
title: os.wlak() consider some symlinks as dirs instead of non-dirs -
os.walk() consider some symlinks as dirs instead of non-dirs
___
Python tracker rep...@bugs.python.org
Changes by Benjamin Peterson benja...@python.org:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12968
___
Changes by sbt shibt...@gmail.com:
Removed file: http://bugs.python.org/file23141/mp_fork_exec.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8713
___
sbt shibt...@gmail.com added the comment:
Small fix to patch.
--
Added file: http://bugs.python.org/file23142/mp_fork_exec.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8713
___
Alan McIntyre alan.mcint...@gmail.com added the comment:
I also can't see any file operations that might occur between the two .tell()
calls, and a full test pass (including test_zipfile64) on the py3k development
branch doesn't turn up any problems on Linux (2.6.38, x86_64) for me, so I
Éric Araujo mer...@netwok.org added the comment:
Alright, I’ll propose piecemeal patches.
Georg, two questions:
1) In the tutorial, should classes with no target use ``MyClass`` or
:class:`!MyClass`?
2) Should file extensions use ``.py`` or :file:`.py`? We currently have both.
--
Alan McIntyre alan.mcint...@gmail.com added the comment:
I re-checked testzip-patch3.diff since some time has passed since I last
commented on it, and it still seems to work ok (the small test_zipfile.py block
failed to apply, but that's easy enough to do manually). Passes full test run,
Alan McIntyre alan.mcint...@gmail.com added the comment:
So far I haven't had the opportunity to sit down and write up a lenient
zipfile handling patch; my apologies to those that could really use one. If
somebody does propose a patch, I'll be glad to test and review it.
I suppose I would
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12397
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
I wonder whether it is http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453.
The demo script from there crashes both on debian-arm and Ubuntu Lucid,
but this specific segfault only occurs on debian arm.
Attached is a minimal C test
Éric Araujo mer...@netwok.org added the comment:
This is a strange bug. I added a test using -r server2, using the
already-existing PYPIRC_LONG_PASSWORD string as .pypirc contents. The test
passes. To make sure changing one test would not affect another one, I created
a new .pypirc file,
Georg Brandl ge...@python.org added the comment:
Basically, :class:`!Foo` has no advantage over ``Foo``. The no-linking syntax
is really only there for completeness, but I would prefer the plainer and
easier to read (in source) ``Foo``.
For files, :file: really only has an advantage if you do
New submission from Damian atag...@gmail.com:
Hi, when using terminal coloring codes (for instance '\x1b[32mhello
world\x1b[0m' for a green 'hello world') the raw_input function and readline
module behave well except under a very specific use case...
Stefan Krah stefan-use...@bytereef.org added the comment:
I think I got it: pthread_setaffinity_np() does not crash.
`man sched_setaffinity` is slightly ambiguous, but there is this remark:
(If you are using the POSIX threads API, then use pthread_setaffinity_np(3)
instead of
Charles-François Natali neolo...@free.fr added the comment:
I think I got it: pthread_setaffinity_np() does not crash.
Nice.
Out of curiosity, I just looked at the source code, and it just does
sched_setaffinity(thread-tid), so you can do the same with
sched_setaffinity(syscall(SYS_gettid))
Meador Inge mead...@gmail.com added the comment:
Yes, please let's not add any new __int__-based duck typing here;
Mark, just to clarify a bit, the behavior is already there in the array module
(by way of 'PyLong_AsLong'). The fact that it is there was picked up on a code
review for this
STINNER Victor victor.stin...@haypocalc.com added the comment:
However, I don't think we should/could add this to the posix module:
it expects a pthread_t instead of a PID, to which we don't have access.
We already have such function:
Jeremy Kloth jeremy.kloth+python-trac...@gmail.com added the comment:
The attached patch seems to work as-is. That is, just testing for `self.path`
as the prefix. On Windows, at least, the paths in RECORD are always absolute.
Further changes will be necessary, of course, once changes for
Mark Dickinson dicki...@gmail.com added the comment:
Mark, just to clarify a bit, the behavior is already there in the array module
Okay, understood. But the new 'long long' support provided by this patch still
allows for __int__-based duck typing, right?
array('Q', [1, 2, Decimal(3.2)])
Stefan Krah stefan-use...@bytereef.org added the comment:
Charles-François Natali rep...@bugs.python.org wrote:
Out of curiosity, I just looked at the source code, and it just does
sched_setaffinity(thread-tid), so you can do the same with
sched_setaffinity(syscall(SYS_gettid)) for the
New submission from Adam a...@netbsd.org:
int_pow() (from Objects/intobject.c) shows incorrect results when Python is
compiled with Clang (llvm.org); long story short: int_pow() function should use
'unsigned long' type instead of 'long' or some code gets optimised out.
Please, refer to this
Stefan Krah stefan-use...@bytereef.org added the comment:
I think this is related to issue #11149. Can you try compiling with
-fwrapv?
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12973
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
There is an inconsistency in used header and library.
attr/xattr.h and libattr.so belong to attr package
(http://savannah.nongnu.org/projects/attr).
glibc provides sys/xattr.h and libc.so.
Both libattr.so and libc.so
Charles-François Natali neolo...@free.fr added the comment:
If we have access (and as I understood from Victor's post we do):
pthread_getaffinity_np() also exists on FreeBSD, which would be
an advantage.
Yes, but I see several drawbacks:
- as noted by Victor, it's really easy to crash the
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 33f7044b5682 by Benjamin Peterson in branch 'default':
Use xattr functions from sys/xattr.h instead of attr/xattr.h (closes #12720)
http://hg.python.org/cpython/rev/33f7044b5682
--
resolution: - fixed
Stefan Krah stefan-use...@bytereef.org added the comment:
I can reproduce your results with a recent clang. gcc has similar
optimization behavior, but for gcc ./configure automatically adds
-fwrapv, which prevents the incorrect results.
I'm closing this as a duplicate of #11149.
--
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +a...@netbsd.org, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11149
___
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Recent clang and Python2.7 (without the patch):
Python 2.7.2+ (2.7:e8d8eb9e05fd, Sep 14 2011, 00:35:51)
[GCC 4.2.1 Compatible Clang 3.0 (trunk 139637)] on freebsd8
Type help, copyright, credits or license for more information.
2**63
STINNER Victor victor.stin...@haypocalc.com added the comment:
as noted by Victor, it's really easy to crash the interpreter
by passing an invalid thread ID, which IMHO, should be avoided
at all cost
Do you mean that signal.pthread_kill() should be removed? This function is very
useful and
STINNER Victor victor.stin...@haypocalc.com added the comment:
Recent clang and Python2.7 (without the patch):
2**64
0
Does the test suite catch this bug?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11149
STINNER Victor victor.stin...@haypocalc.com added the comment:
So, can we close this issue?
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12946
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
According to the following article, a fsync is also needed on the directory
after a rename. I don't understand if is it always needed for an atomic rename,
or if we only need it for the atomic write pattern.
STINNER Victor victor.stin...@haypocalc.com added the comment:
According to http://docs.python.org/library/threading.html#condition-objects,
threading.Condition is a class.
Nope, it's a factory, and it's written in the doc:
threading.Condition()
A factory function that returns a new
STINNER Victor victor.stin...@haypocalc.com added the comment:
@eric: The doc has to be updated:
http://docs.python.org/dev/library/threading.html#threading.activeCount
threading.Condition()
A factory function that returns a new condition variable object. A condition
variable allows one or
Nikolaus Rath nikol...@rath.org added the comment:
On 09/13/2011 07:41 PM, STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
According to
http://docs.python.org/library/threading.html#condition-objects,
threading.Condition is a class.
Nope, it's a
Changes by Caio Romão caioro...@gmail.com:
Removed file: http://bugs.python.org/file23118/caioromao-fix-12930-v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12930
___
Caio Romão caioro...@gmail.com added the comment:
Third version, with slightly less code and my name added to the Misc/ACKS file.
--
Added file: http://bugs.python.org/file23146/caioromao-fix-12930-v3.patch
___
Python tracker rep...@bugs.python.org
New submission from Meador Inge mead...@gmail.com:
When reviewing the fix for issue1172711 it was discovered that the 'array'
module allows for '__int__' conversions:
import array, struct
a = array.array('L', [1,2,3])
class T(object):
... def __init__(self, value):
...
Meador Inge mead...@gmail.com added the comment:
Okay, understood. But the new 'long long' support provided by this patch
still allows for __int__-based duck typing, right?
Yes, but ...
That's the new duck typing I meant. I see this acceptance of things with an
__int__ method as a
ben thelen_...@yahoo.com added the comment:
Error had been raised when installing the distribute package, but it could be
raised on any other usage as sys.stdout does not have an 'error' attribute.
From: Éric Araujo rep...@bugs.python.org
To: thelen_...@yahoo.com
Sent: Tuesday, 13
Meador Inge mead...@gmail.com added the comment:
Updated patch with the 'Py_ssize_t' fixes.
--
Added file: http://bugs.python.org/file23148/issue-1172711.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1621
___
___
Python-bugs-list mailing list
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11149
___
___
Python-bugs-list mailing list
Brandon Craig Rhodes bran...@rhodesmill.org added the comment:
In case Google brings anyone else to this bug: this error typically indicates
that a `threading.py` which is not actually the Standard Library's `threading`
module has somehow wound up on an earlier path in `sys.path` and is
Ned Deily n...@acm.org added the comment:
It turns out that supporting a framework path name that contains spaces (or
other special characters) is a much more pervasive change that I had originally
expected. That's because the path specified by ./configure --enable-framework=
also becomes
Meador Inge mead...@gmail.com added the comment:
Note that there is at least one other place where alloca() is
used with potentially large values:
Ouch! I found three more crashers (including the one you found)
by grepping for 'alloca' in ctypes:
from ctypes import *
T = type('x' * 2 **
Stefan Behnel sco...@users.sourceforge.net added the comment:
I gave two reasons why this function can fail, and one turns out to be
assumed-to-be-dead code. So, no, there are two issues now, one with the
documentation, one with the code.
--
___
Changes by Alex Gaynor alex.gay...@gmail.com:
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1621
___
___
Python-bugs-list mailing
Eric Snow ericsnowcurren...@gmail.com added the comment:
Finally had a chance to get back to this. Here's a new patch in response to
Nick's review.
My only concern is the new _PyEval_EvalFunctionCode function. It is basically
the existing PyEval_EvalCodeEx function with an extra parameter.
Charles-François Natali neolo...@free.fr added the comment:
Do you mean that signal.pthread_kill() should be removed? This function is
very useful and solve some issues that cannot be solved differently. At the
same time, I don't think that it's possible to workaround the crashes. At
73 matches
Mail list logo
