Stefan Krah added the comment:
I completely removed faulthandler from e91ad9669c08 and the problem
still occurs (with the same broken backtrace).
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.7
It is a bit unsatisfying that the segfault isn't reproducible with
the earlier revision, but ther
Stefan Krah added the comment:
STINNER Victor wrote:
> > Traceback with faulthandler disabled: ...
>
> How did you disabled faulthandler?
That was a run with all faulthandler references removed from regrtest.py.
But as I said in my previous mail, I also did a run using e91a
New submission from Stefan Krah :
In one of the error branches PyLong_AsSize_t() returns (unsigned long)-1
instead of (size_t)-1.
--
components: Interpreter Core
files: pylong_as_size_t.diff
keywords: patch
messages: 143896
nosy: mark.dickinson, skrah
priority: normal
severity: normal
New submission from Stefan Krah :
I think the integer objects documentation could be clearer on a
couple of points:
- Despite being listed under "Concrete Objects Layer", some
functions implicitly accept anything with an __int__()
method. Currently only the PyL
Changes by Stefan Krah :
--
assignee: docs@python -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12965>
___
___
Python-bugs-list mai
Stefan Krah added the comment:
> Yep, clearly a bug. Please fix!
Done, thanks for reviewing.
Victor, I don't think we need a unit test for this. I plan to go
over some modules with gcov in the future, and I'll include
longobject.c.
--
resolution: -> fixed
status
Stefan Krah added the comment:
I made the observation on Rietveld that the following code is never
executed by the test suite. The same applies to similar existing
passages in arraymodule.c:
http://bugs.python.org/review/1172711/diff/3310/10310#newcode394
Meador correctly pointed out that
Stefan Krah 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 tracker
<h
Stefan Krah 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 () from /lib/ld-linux
Stefan Krah 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 of known good glibc
Stefan Krah 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 case that only crashes on
Stefan Krah 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 sched_setaffinity().)
I&#
Stefan Krah added the comment:
Charles-François Natali 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 current thread.
sched_setaffi
Stefan Krah added the comment:
I think this is related to issue #11149. Can you try compiling with
-fwrapv?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah 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.
--
resolution: -> d
Changes by Stefan Krah :
--
nosy: +a...@netbsd.org, skrah
___
Python tracker
<http://bugs.python.org/issue11149>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah 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 "licen
Stefan Krah added the comment:
> Does the test suite catch this bug?
I think all of those fail due to the bug in pow():
20 tests failed:
test_array test_builtin test_bytes test_decimal test_float
test_fractions test_getargs2 test_index test_int test_itertools
test_list test_l
Stefan Krah added the comment:
The OS X buildbots fail to compile posixmodule.c:
gcc -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes-I. -I./Include
-DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ‘try_getxattr’:
./Modules
Stefan Krah added the comment:
I'd prefer to disable the misbehaving functions entirely on arm.
With the patch this combination of tests now works:
./python -m test -uall test_posix test_nntplib
If you think the patch is good, I can run the whole test suite, too.
[I'd rathe
Stefan Krah added the comment:
No, that's me playing around. I tried to use clang as the compiler
for the build slave. I can't figure out yet why the segfaults occur.
When I'm running the test manually, everything seems to work.
--
___
Stefan Krah added the comment:
I'm completely puzzled by this. I ran *all* tests manually on the same
machine with clang with the same parameters as the buildbot
(--with-pydebug, make buildbottest) and they pass.
I reverted the buildbot to gcc, it'll be green again soon.
Closing
Stefan Krah added the comment:
== CPython 2.7.2+ (2.7:a698ad2741da+, Sep 15 2011, 00:17:28) [GCC 4.2.1
Compatible Clang 3.0 (trunk 139637)]
== FreeBSD-8.0-RELEASE-amd64-64bit-ELF little-endian
== /usr/home/stefan/pydev/cpython/build/test_python_71451
With clang 3.0 from trunk, the pow
Stefan Krah added the comment:
The buildbots are fine, though I think that in this instance
Gentoo-Non-Debug-3.x is the only bot that actually exercises
the new code path.
So I tested manually on FreeBSD/clang-3.0 and I don't see
anything surprising.
--
resolution: -> fix
New submission from Stefan Krah :
I'm not sure if this is a good idea: I wonder if it would be an option
to check for overflow behavior at the bottom of ./configure and print a
warning. The patch appears to work for gcc, clang and suncc. It would
have caught the problem in #12973.
The
Changes by Stefan Krah :
--
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12985>
___
___
Python-bug
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23164/listobject_overflow.diff
___
Python tracker
<http://bugs.python.org/issue12973>
___
___
Python-bug
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23165/itertools_overflow.diff
___
Python tracker
<http://bugs.python.org/issue12973>
___
___
Python-bug
Stefan Krah added the comment:
With issue12975.diff, listobject_overflow.diff and itertools_overflow.diff
I don't get any more failures.
Also, of course issue12975.diff looks correct to me if we assume:
http://mail.python.org/pipermail/python-dev/2009-December/094392.html
http://yarchiv
Stefan Krah added the comment:
My rationale was something like this: If a compiler optimizes away signed
arithmetic overflow, this particular comparison will most likely be in
the set of optimizations, since it seems like low hanging fruit.
Of course it doesn't guarantee wrapping behavi
Stefan Krah added the comment:
Mark Dickinson wrote:
> Well, they're all in the standard, which is publicly available.
I have the real thing. :)
> The correctness of the patch depends on:
> (2) an assumption that the C implementation will never raise an
> 'implemen
Stefan Krah added the comment:
I just discovered that struct packs pointers from objects with an
__index__() method. Is that intentional?
>>> import struct
>>> class IDX(object):
... def __init__(self, value):
... self.value = value
... def __index__(self):
.
Stefan Krah added the comment:
> I am OK with applying the fix for this issue first.
I also think this should be committed first.
--
___
Python tracker
<http://bugs.python.org/issue1
Stefan Krah added the comment:
Mark Dickinson wrote:
> Yes, that's intentional. When use of __int__ was deprecated, a bug
> report popped up from someone who wanted to be able to have their own
> objects treated as integers for the purposes of struct.pack.
> (I don
Stefan Krah added the comment:
I think you may want to ask these questions on the Python mailing list:
http://mail.python.org/mailman/listinfo/python-list
This is the Python bug-tracker, and it's not obvious to me that
any of your points is a bug in Python.
--
nosy: +
Stefan Krah added the comment:
1) I cannot reproduce this.
2) ld is the linker and not the compiler.
3) and 4) Should definitely be asked on python-list.
--
resolution: -> works for me
stage: -> committed/rejected
status: open -&g
Stefan Krah added the comment:
Meador Inge wrote:
> The behavior around '__int__' in previous versions seems somewhat accidental.
I think struct followed the functions in longobject.c, which is not
really consistent with respect to duck typing. See also #12965 or
http://bu
Stefan Krah added the comment:
I cannot reproduce the crash on:
Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl
GNU/Linux
Since the old (arm) port is deprecated, I'm closing this.
--
resolution: -> wont fix
stage: test needed -> committ
Stefan Krah added the comment:
I can reproduce the leak with Python 2.5.4, but not with Python 2.6.5
or Python 3.2.
Python 2.5.4 is an ancient version. Please upgrade to Python 2.7
or Python 3.2. If the leak still exists, just respond to this issue
and it will be opened again automatically
New submission from Stefan Krah :
peephole.c: CONST_STACK_TOP(x) has an unused parameter.
--
components: Interpreter Core
files: peephole_unused_parameter.diff
keywords: patch
messages: 144189
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23185/4492afe05a07.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Revision 4492afe05a07 allows memoryview to handle objects with an
__index__() method. This is for compatibility with the struct module
(See also #8300).
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
The README looks outdated. This isn't surprising, since probably no one
here has access to the HP compiler.
If you want to improve it, please try this:
make distclean
./configure CC=cc CFLAGS="+DD64"
make test
I don't think the linker shou
Stefan Krah added the comment:
This doesn't look right to me: If (rdn != NULL) && (PyList_Size(rdn) > 0),
rdn is already decremented.
There is a leak though if (rdn != NULL) && (PyList_Size(rdn) == 0).
--
nosy: +skrah
_
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion -> _ssl.c:
resource is not released before returning from the function
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
> I think, it is a good idea to improve the Readme for this issue.
+1.
Wah Meng: Building everything is not enough, does 'make test'
complete successfully?
For gcc, Python2.7 relies on two critical options, -fno-strict-aliasing
and -fwrapv. Th
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
structseq.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
_ctypes.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
pyexpat.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
dictobject.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Extension Modules
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Interpreter Core
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Extension Modules
title: _ssl.c: resource is not released before returning from the function ->
_ssl.c: refleak
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Extension Modules
stage: -> patch review
title: Resource is not released before returning from the functiion ->
selectmodule.c: refleak
versions: +Python 3.3
___
Python tracker
<http://bugs.p
Changes by Stefan Krah :
--
components: +Extension Modules
stage: -> patch review
title: Resource is not released before returning from the functiion ->
_collectionsmodule.c: refleak
versions: +Python 3.3
___
Python tracker
<http://bugs.p
Changes by Stefan Krah :
--
title: bytearrayobject.c: Resource is not released before returning from the
functiion -> bytearrayobject.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Thanks for checking the patch! Closing this now.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
> However, the new binary is still not able to start a new thread from the
> thread module.
Traceback?
mach/cthreads.h is only relevant for Hurd, as far as I can see.
> configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g
> -L
Stefan Krah added the comment:
> If the C accelerator for decimal gets decimal performance close to
> floats (which I doubt, because it has to do much more), it could be
> very useful for me. What is its estimated time to completion?
It is finished and awaiting review (See #7652). Th
Stefan Krah added the comment:
> BTW, what is the status of cdecimal?
I just wrote the same in another issue, but not everyone is subscribed
to that:
I think cdecimal is finished and production ready. The version in
http://hg.python.org/features/cdecimal#py3k-cdecimal
is the same as w
Stefan Krah added the comment:
> Possibly related to http://bugs.python.org/issue11149?
Maybe I missed it in the links you gave, but that is easily
settled by compiling with and without -fwrapv.
--
nosy: +skrah
___
Python tracker
&l
Stefan Krah added the comment:
To me this looks like stdio.h should be included as well. Could
you try the patch?
--
keywords: +patch
Added file: http://bugs.python.org/file23262/issue-13057.diff
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
It's more a straight duplicate of #12973, but the underlying cause
(signed integer overflow) is the same. For people who are finding
this via a search engine: A lot of bugs have been fixed in #12973,
but even if the test suite passes without -fwrapv it is *
Stefan Krah added the comment:
Wah Meng: I think there are a couple of misconceptions that
need to be cleared up:
1) Georg's complaint was about the links to http://dyno.freescale.net/
in you posts.
2) This is not a support hotline but a *bug tracker*. Since
the bug in configur
Stefan Krah added the comment:
I think this is a duplicate of #12788.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> test_email fails with -R
___
Python tracker
<http://
New submission from Stefan Krah :
Got this failure on Debian lenny amd64:
[1/1] test_signal
test test_signal failed -- Traceback (most recent call last):
File "/home/stefan/cpython/Lib/test/test_signal.py", line 339, in test_pending
""", *signals)
File "
New submission from Stefan Krah :
I think a couple of leaks were introduced by the pep-393
changes (see the patch).
--
components: Interpreter Core
files: pep-393-leaks.diff
keywords: patch
messages: 144719
nosy: haypo, loewis, skrah
priority: normal
severity: normal
stage: patch review
Changes by Stefan Krah :
--
title: : memory leaks -> pep-393: memory leaks
___
Python tracker
<http://bugs.python.org/issue13085>
___
___
Python-bugs-list mai
Changes by Stefan Krah :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue13084>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue6632>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
The PEP-393 changes apparently fix this leak; at least I can't reproduce
it in default any longer (but still in 3.2).
--
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Krah :
Seen in test_mailbox:
==31621== 6 bytes in 2 blocks are definitely lost in loss record 27 of 10,370
==31621==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31621==by 0x5271A5: parsetok (parsetok.c:179)
==31621==by 0x526E8A
New submission from Stefan Krah :
Seen in test_multiprocessing:
==31662== 37 bytes in 1 blocks are definitely lost in loss record 629 of 10,548
==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==by 0x53BBE9: PyBytes_FromStringAndSize (bytesobject.c:98)
==31662==by
New submission from Stefan Krah :
Seen in test_multiprocessing:
==31662== 44 bytes in 1 blocks are definitely lost in loss record 687 of 10,548
==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==by 0x41CC27: PyMem_Malloc (object.c:1699)
==31662==by 0x127D9F51: resize
New submission from Stefan Krah :
I found a couple of additional leaks related to the PEP-393 changes.
--
components: Interpreter Core
files: pep-393-leaks-2.diff
keywords: patch
messages: 144767
nosy: loewis, skrah
priority: normal
severity: normal
stage: patch review
status: open
Stefan Krah added the comment:
Patch looks good to me (and it fixes the problem).
--
___
Python tracker
<http://bugs.python.org/issue13084>
___
___
Python-bug
New submission from Stefan Krah :
I can't see what this code is supposed to accomplish (see patch):
while (collend < end) {
if ((0 < *collend && *collend < 256) ||
!Py_UNICODE_ISSPACE(*collend) ||
Py_UNICODE_TODECIMAL(*collend))
break
Stefan Krah added the comment:
The automatic conversion of 'u' to 'I' or 'L' causes test_buffer
(PEP-3118 repo) to fail:
# Not implemented formats. Ugly, but inevitable. This is the same as
# issue #2531: equality is also used for membership testing and must
# re
Changes by Stefan Krah :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13072>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
>It would be better to use a format for a Py_UCS4 string, but struct doesn't
>support such type.
PEP-3118 suggests for the extended struct syntax:
'c' -> ucs-1 (latin-1) encoding
&
Stefan Krah added the comment:
STINNER Victor wrote:
> > # Not implemented formats. Ugly, but inevitable. This is the same as
> > # issue #2531: equality is also used for membership testing and must
> > # return a result.
> > a = array.array('u&
Stefan Krah added the comment:
I haven't seen this in a while, so let's assume it's fixed.
--
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http:/
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Stefan Krah :
The FreeBSD-amd64 and Fedora buildbots are recently failing with:
==
ERROR: test_thishost (test.test_urllib.Utility_Tests)
Test the urllib.request.thishost utility function returns a tuple
Changes by Stefan Krah :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> urllib.request.thishost() returns a garbage value
type: -> behavior
___
Python tracker
<http://bugs.pyt
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13104>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
/etc/hosts was incomplete; works fine now. Closing again.
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Naturally, as soon as I declare it fixed, it occurs again:
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/326
--
status: closed -> open
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
I think the whole security paragraph should be deleted. The
discussion on python-dev has overstated the risks.
Anyone who is *that* security conscious and in effect does
not trust the Python committers should also audit the thousands
of lines of ./configure and
New submission from Stefan Krah :
The Fedora bot fails since yesterday:
Breakpoint 1, builtin_id (self=, v=Traceback
(most recent call last):
File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line
1329, in to_string
return pyop.get_truncated_repr(MAX_
Stefan Krah added the comment:
I temporarily changed the Fedora bot to run Fedora-14-i386. The
same failures can be observed:
==
ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase
Stefan Krah added the comment:
test_errno fails quite often on FreeBSD:
==
FAIL: test_errno (test.test_select.SelectTestCase)
--
Traceback (most recent call
Stefan Krah added the comment:
Hmm, maybe this is a FreeBSD bug:
http://osdir.com/ml/freebsd-bugs/2011-03/msg00201.html
--
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
I'm not sure it's exactly the same FreeBSD bug as in kern/155606,
since I can also reproduce the test_errno failure --without-threads.
Seems good to skip the test though.
--
___
Python tracker
<http://bu
New submission from Stefan Krah :
The failures seen on the Fedora buildbot are caused by the fact that
INSTALLED_FILES does not use __pycache__:
[stefan@fedora-14-i386 foo]$ cat
build/bdist.linux-i686/rpm/BUILD/foo-0.1/INSTALLED_FILES
/usr/local/lib/python3.3/site-packages/foo.py
/usr/local
Stefan Krah added the comment:
For the buildbot failures see #13307. I think that it's indeed a
different issue, since AFAIK __pycache__ didn't exist when this one
was opened.
--
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
The buildbot runs as non-root, so it should reproduce this
issue (but it's green).
The original report was for 2.6/3.1, so I think closing this as
out-of-date is reasonable.
--
___
Python tracker
Changes by Stefan Krah :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue12998>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
Looking at it again, the intention was probably to increment
collend so that it points to the first non-garbage character
(or '\0'). If that's the case, the loop should be something
like this:
while (collend < end) {
if ((0 < *coll
Stefan Krah added the comment:
My last comment could be misinterpreted: This *is* actually
already fixed in features/pep-3118.
--
versions: +Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/issue7
1 - 100 of 3396 matches
Mail list logo
