[issue45470] possible bug in datetime.timestamp()
New submission from Stefan : I noticed that there is a difference between intervals when computed from timedeltas vs timestamps. Is this a bug? Thanks! In [2]: import datetime as datet In [3]: d0 = datet.datetime(2016,3,27) In [4]: d1 = datet.datetime(2016,3,28) In [5]: (d1-d0).total_seconds()/3600 Out[5]: 24.0 In [6]: (d1.timestamp()-d0.timestamp())/3600 Out[6]: 23.0 -- messages: 403917 nosy: stef priority: normal severity: normal status: open title: possible bug in datetime.timestamp() type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45470] possible bug in datetime.timestamp()
Stefan added the comment: sorry it's resolved. it was a timezone issue: In [2]: d0 = datet.datetime(2016,3,27,tzinfo=datet.timezone.utc) In [3]: d1 = datet.datetime(2016,3,28,tzinfo=datet.timezone.utc) In [4]: (d1-d0).total_seconds()/3600 Out[4]: 24.0 In [5]: (d1.timestamp()-d0.timestamp())/3600 Out[5]: 24.0 -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36980] pass-by-reference clues
New submission from stefan : I often get unexpected results when a called function results in a change in a variable because the function gets a pass by reference. For example, consider this snippet of code that manipulates the first column of a 3x3 matrix that it gets. ~~~ import numpy as np def changeValue(kernel): kernel[0,0]=kernel[0,0]+ 2 kernel[1,0]=kernel[1,0]+ 2 kernel[2,0]=kernel[2,0]+ 2 return kernel myKernel = np.array(( [0, -1, 0], [-1, 5, -1], [0, -1, 0]), dtype="int") CVkernel=myKernel print(CVkernel) a=changeValue(myKernel) print(a) print(CVkernel) ~~~ I get the following output [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] [[ 2 -1 0] [ 1 5 -1] [ 2 -1 0]] [[ 2 -1 0] [ 1 5 -1] [ 2 -1 0]] The value of myKernel clobbers CVkernel. I think there is an unintentional call-by-reference (pass-by-reference?) going on but I am not sure why. If I define the function slightly differently def changeValue2(kernel): kernel=kernel + 2 return kernel Then CVkernel is left untouched [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] [[2 1 2] [1 7 1] [2 1 2]] [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] What is going on here? EDIT Even when I use a 'safe' function call that does not clobber CVkernel, like kernel=kernel + 2 , the id of myKernel and CVkernel are the same. id of myKernel 139994865303344 myKernel [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] id of CVKernel 139994865303344 CVKernel [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] **call made to changeValue2** id of myKernel 139994865303344 myKernel [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] id of CVKernel 139994865303344 CVKernel [[ 0 -1 0] [-1 5 -1] [ 0 -1 0]] output a [[2 1 2] [1 7 1] [2 1 2]] Shouldn't the id of each variable be different if they are different instances? Would it possible for the python interpreter/compiler to let me know when a function is going to clobber a variable that is not used in the function or passed to the function or returned by the function -- messages: 342967 nosy: skypickle priority: normal severity: normal status: open title: pass-by-reference clues type: behavior ___ Python tracker <https://bugs.python.org/issue36980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36980] pass-by-reference clues
stefan added the comment: Thank you for your reply and the lucid explanation. On Monday, May 20, 2019, 9:17:34 PM EDT, Josh Rosenberg wrote: Josh Rosenberg added the comment: 1. This is a bug tracker for bugs in the Python language spec and the CPython interpreter, not a general problem solving site. 2. The ids will differ for changeValue2 if you actually call it (kernel = kernel + 2 requires the the old id of kernel differ from the new id, because they both exist simultaneously, and are different objects); I'm guessing you're calling the wrong function or printing the ids of the wrong variables. 3. "Would it possible for the python interpreter/compiler to let me know when a function is going to clobber a variable that is not used in the function or passed to the function or returned by the function" Every bit of clobbering you're seeing involves a variable passed to the function (and sometimes returned by it). CVkernel=myKernel just made two names that bind to the same underlying object, so passing either name as an argument to a function that modifies its arguments will modify what is seen from both names. That's how mutable objects work. This is briefly addressed in the tutorial here: https://docs.python.org/3/tutorial/classes.html#a-word-about-names-and-objects . As a general rule, Python built-ins *either* modify their arguments in place and return nothing (None) *or* return new values leaving the arguments unmodified. It's a matter of programmer discipline to adhere to this practice in your own code (numpy does make it harder, since it uses views extensively, making sli cing not an effective way to copy inputs). All that said, this isn't a bug. It's a longstanding feature of Python alias arguments to avoid expensive deep copies by default; the onus is on the function writer to copy if needed, or to document the behavior if mutation of the arguments is to occur. -- nosy: +josh.r ___ Python tracker <https://bugs.python.org/issue36980> ___ -- ___ Python tracker <https://bugs.python.org/issue36980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36980] pass-by-reference clues
stefan added the comment: Thank you for your reply and the lucid explanation. On Monday, May 20, 2019, 9:15:42 PM EDT, Steven D'Aprano wrote: Steven D'Aprano added the comment: Hi Stefan, and welcome. This is not a help desk, you really should ask elsewhere for explanations of how Python works. There are no bugs here: what you are seeing is standard pass-by-object behaviour. You are misinterpreting what you are seeing. Python is never pass by reference or pass by value. https://en.wikipedia.org/wiki/Evaluation_strategy https://www.effbot.org/zone/call-by-object.htm *All* function objects, whether strings, ints, lists or numpy arrays, are passed as objects. If you want to make a copy, you have to explicitly make a copy. If you don't, and you mutate the object in place, you will see the mutation in both places. > Shouldn't the id of each variable be different if they are different > instances? Not necessarily: IDs can be reused. Without seeing the actual running code, I can't tell if the IDs have been used or if they are the same ID because they are the same object. > Would it possible for the python interpreter/compiler to let me know when a > function is going to clobber a variable that is not used in the function or > passed to the function or returned by the function Python never clobbers a variable not used in the function. It may however mutate an object which is accessible from both inside and outside a function. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36980> ___ -- ___ Python tracker <https://bugs.python.org/issue36980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Stefan added the comment: I have exactly the same problem. Is there a thread-safe alternative to execute subprocesses in threads? -- nosy: +santoni ___ Python tracker <http://bugs.python.org/issue1731717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16392] [doc] import crashes on circular imports in ext modules
Stefan Behnel added the comment: Given that PEP-489 has landed in Py3.5, which is already retired and has been for more than a year, I think we can just close this issue as outdated. -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue16392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45711] Simplify the interpreter's (type, val, tb) exception representation
Change by Stefan Behnel : -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue45711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45711] Simplify the interpreter's (type, val, tb) exception representation
Stefan Behnel added the comment: FYI, we track the Cython side of this in https://github.com/cython/cython/issues/4500 -- ___ Python tracker <https://bugs.python.org/issue45711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45321] Module xml.parsers.expat.errors misses error code constants of libexpat >=2.0
Stefan Behnel added the comment: New changeset e18d81569fa0564f3bc7bcfd2fce26ec91ba0a6e by Sebastian Pipping in branch 'main': bpo-45321: Add missing error codes to module `xml.parsers.expat.errors` (GH-30188) https://github.com/python/cpython/commit/e18d81569fa0564f3bc7bcfd2fce26ec91ba0a6e -- ___ Python tracker <https://bugs.python.org/issue45321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45321] Module xml.parsers.expat.errors misses error code constants of libexpat >=2.0
Change by Stefan Behnel : -- components: +XML resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1
Stefan Behnel added the comment: I'd like to ask for clarification regarding issue 45321, which adds the missing error constants to the `expat` module. I consider those new features – it seems inappropriate to add new module constants in the middle of a release series. However, in this ticket here, the libexpat version was updated all the way back to Py3.6, to solve a security issue. Should we also backport the error constants then? -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue44394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
Stefan Pochmann added the comment: The error occurs when you do code.strip()[0] when code is " ", not "u2". -- nosy: +Stefan Pochmann ___ Python tracker <https://bugs.python.org/issue46302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45569] Drop support for 15-bit PyLong digits?
Stefan Behnel added the comment: Cython should be happy with whatever CPython uses (as long as CPython's header files agree with CPython's build ;-) ). I saw the RasPi benchmarks on the ML. That would have been my suggested trial platform as well. https://mail.python.org/archives/list/python-...@python.org/message/5RJGI6THWCDYTTEPXMWXU7CK66RQUTD4/ The results look ok. Maybe the slowdown for pickling is really the increased data size of integers. And it's visible that some compute-heavily benchmarks like pyaes did get a little slower. I doubt that they represent a real use case on such a platform, though. Doing any kind of number crunching on a RasPi without NumPy would appear like a rather strange adventure. That said, if we decide to keep 15-bit digits in the end, I wonder if "SIZEOF_VOID_P" is the right decision point. It seems more of a "has reasonably fast 64-bit multiply or not" kind of decision – however that translates into code. I'm sure there are 32-bit platforms that would actually benefit from 30-bit digits today. If we find a platform that would be fine with 30-bits but lacks a fast 64-bit multiply, then we could still try to add a platform specific value size check for smaller numbers. Since those are common case, branch prediction might help us more often than not. But then, I wonder how much complexity this is even worth, given that the goal is to reduce the complexity. Platform maintainers can still decide to configure the digit size externally for the time being, if it makes a difference for them. Maybe switching off 15-bits by default is just good enough for the next couple of years to come. :) -- ___ Python tracker <https://bugs.python.org/issue45569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46535] Possible bug: pdb causes exception
New submission from Stefan Ecklebe :
Consider a script called snippet.py, containing the lines
--
import numpy as np
import pandas as pd
np.finfo(float)
idx = pd.MultiIndex.from_tuples([(1, 2)])
np.finfo(float)
print("Done")
--
When running via 'python snippet.py' no errors occur. However when running via
'python -m pdb snippet.py' the following happens:
> snippet.py(1)()
-> import numpy as np
(Pdb) r
--Return--
> snippet.py(6)()->None
-> np.finfo(float)
(Pdb) c
Traceback (most recent call last):
File "VENV/lib/python3.10/site-packages/numpy/core/getlimits.py", line 459,
in __new__
dtype = numeric.dtype(dtype)
TypeError: 'NoneType' object is not callable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.10/pdb.py", line 1723, in main
pdb._runscript(mainpyfile)
File "/usr/lib/python3.10/pdb.py", line 1583, in _runscript
self.run(statement)
File "/usr/lib/python3.10/bdb.py", line 597, in run
exec(cmd, globals, locals)
File "", line 1, in
File "snippet.py", line 6, in
np.finfo(float)
File "VENV/lib/python3.10/site-packages/numpy/core/getlimits.py", line 462,
in __new__
dtype = numeric.dtype(type(dtype))
TypeError: 'NoneType' object is not callable
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
Commenting the MultiIndex line will will get rid of the problem but I am not
quite sure why.
Please note that this error only occurs if the script is run via 'r' in pdb.
Running via 'c' does not cause any problems.
Therefore, I suspect that the problem may be with pdb instead of the external
packages.
My setup:
$ python --version
Python 3.10.1
$ pip list | grep numpy
numpy1.22.1
$ pip list | grep pandas
pandas 1.4.0
--
components: Library (Lib)
messages: 411738
nosy: cklb
priority: normal
severity: normal
status: open
title: Possible bug: pdb causes exception
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46535>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46535] Possible bug: pdb causes exception
Change by Stefan Ecklebe : -- type: crash -> behavior ___ Python tracker <https://bugs.python.org/issue46535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45948] Unexpected instantiation behavior for xml.etree.ElementTree.XMLParser(target=None)
Stefan Behnel added the comment: This is a backwards incompatible change, but unlikely to have a wide impact. I was thinking for a second if it's making the change in the right direction because it's not unreasonable to pass "None" for saying "I want no target". But it's documented this way and lxml does it the same, so I agree that this should be changed to make "None" behave the same as no argument. -- ___ Python tracker <https://bugs.python.org/issue45948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46747] bisect.bisect/insort don't document key parameter
New submission from Stefan Pochmann : The signatures for the versions without "_right" suffix are missing the key parameter: bisect.bisect_right(a, x, lo=0, hi=len(a), *, key=None) bisect.bisect(a, x, lo=0, hi=len(a))¶ bisect.insort_right(a, x, lo=0, hi=len(a), *, key=None) bisect.insort(a, x, lo=0, hi=len(a))¶ https://docs.python.org/3/library/bisect.html#bisect.bisect_right https://docs.python.org/3/library/bisect.html#bisect.insort_right -- assignee: docs@python components: Documentation messages: 413213 nosy: Stefan Pochmann, docs@python priority: normal severity: normal status: open title: bisect.bisect/insort don't document key parameter versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Stefan Behnel added the comment: > Any reasons the PR still not merged? There was dissent about whether these constants should be added or not. It doesn't help to merge a PR that is not expected to provide a benefit. -- ___ Python tracker <https://bugs.python.org/issue24053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value
Stefan Behnel added the comment: The question here is simply, which is considered more important: the default provided by the document, or the default provided by Python. I don't think it's a clear choice, but the way it is now does not seem unreasonable. Changing it would mean deliberate breakage of existing code that relies on the existing behaviour, and I do not see a reason to do that. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46786] embed, source, track, wbr HTML elements not considered empty
Stefan Behnel added the comment: Makes sense. That list hasn't been updated in 10 years. -- versions: -Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value
Stefan Behnel added the comment: > IMHO if the developer doesn't manage the XML itself it is VERY unreasonable > to use the document value and not the developer one. I disagree. If the document says "this is the default if no explicit value if given", then I consider that just as good as providing a value each time. Meaning, the attribute *is* in fact present, just not explicitly spelled out on the element. I would specifically like to avoid adding a new option just to override the way the document distributes its attribute value spelling across DTD and document structure. In particular, the .get() method is the wrong place to deal with this. You can probably configure the parser to ignore the internal DTD subset, if that's what you want. -- ___ Python tracker <https://bugs.python.org/issue46798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46836] [C API] Move PyFrameObject to the internal C API
Stefan Behnel added the comment: I haven't looked fully into this yet, but I *think* that Cython can get rid of most of the direct usages of PyFrameObject by switching to the new InterpreterFrame struct instead. It looks like the important fields have now been moved over to that. That won't improve the situation regarding the usage of CPython internals, but it's probably worth keeping in mind before we start adding new API functions that work on frame objects. -- ___ Python tracker <https://bugs.python.org/issue46836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46848] Use optimized string search function in mmap.find()
New submission from Stefan Tatschner : The mmap.find() in function uses a naive loop to search string matches. This can be optimized “for free” by using libc's memmap(3) function instead. The relevant file is Modules/mmapmodule.c, the relevant function is mmap_gfind(). -- messages: 413902 nosy: rumpelsepp priority: normal severity: normal status: open title: Use optimized string search function in mmap.find() ___ Python tracker <https://bugs.python.org/issue46848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46848] Use optimized string search function in mmap.find()
Stefan Tatschner added the comment: Sorry, I mean memmem(3). :) -- ___ Python tracker <https://bugs.python.org/issue46848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46848] Use optimized string search function in mmap.find()
Change by Stefan Tatschner : -- keywords: +patch pull_requests: +29675 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31554 ___ Python tracker <https://bugs.python.org/issue46848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46389] 3.11: unused generator comprehensions cause f_lineno==None
Stefan Behnel added the comment: Possibly also related, so I though I'd mention it here (sorry if this is hijacking the ticket, seems difficult to tell). We're also seeing None values in f_lineno in Cython's test suite with 3.11a5: File "", line 1, in run_trace(py_add, 1, 2) ^^^ File "tests/run/line_trace.pyx", line 231, in line_trace.run_trace (line_trace.c:7000) func(*args) File "tests/run/line_trace.pyx", line 60, in line_trace.trace_trampoline (line_trace.c:3460) raise File "tests/run/line_trace.pyx", line 54, in line_trace.trace_trampoline (line_trace.c:3359) result = callback(frame, what, arg) File "tests/run/line_trace.pyx", line 81, in line_trace._create_trace_func._trace_func (line_trace.c:3927) trace.append((map_trace_types(event, event), frame.f_lineno - frame.f_code.co_firstlineno)) TypeError: unsupported operand type(s) for -: 'NoneType' and 'int' https://github.com/cython/cython/blob/7ab11ec473a604792bae454305adece55cd8ab37/tests/run/line_trace.pyx No generator expressions involved, though. (Much of that test was written while trying to get the debugger in PyCharm to work with Cython compiled modules.) There is a chance that Cython is doing something wrong in its own line tracing code, obviously. (I also remember seeing other tracing issues before, where the line reported was actually in the trace function itself rather than the code to be traced. We haven't caught up with the frame-internal changes yet.) -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue46389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46786] embed, source, track, wbr HTML elements not considered empty
Stefan Behnel added the comment: New changeset 345572a1a0263076081020524016eae867677cac by Jannis Vajen in branch 'main': bpo-46786: Make ElementTree write the HTML tags embed, source, track, wbr as empty tags (GH-31406) https://github.com/python/cpython/commit/345572a1a0263076081020524016eae867677cac -- ___ Python tracker <https://bugs.python.org/issue46786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46786] embed, source, track, wbr HTML elements not considered empty
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value
Change by Stefan Behnel : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue46798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 there are several glibc issues with __tls_get_addr(): 1) http://www.cygwin.com/ml/libc-hacker/2008-10/msg5.html 2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 If I run the demo script from 2), I get a segfault both on debian-arm as well as on Ubuntu Lucid. So, it may very well be that some recent change in Python exposes a glibc problem. -- ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 e91ad9669c08 but without compiling and linking faulthandler, so that _PyFaulthandler_Init() wouldn't be called. This had the same result, so faulthandler is _not_ the cause of this bug. > > Version 9d658f000419, which is pre-faulthandler, runs without segfaults. > > If it's a regression, you must try hg bisect! It is slow but it is fully > automated! Try something like: > > hg bisect -r > hg bisect -b 9d658f000419 > hg bisect -c 'make && ./python -m test test_urllib2_localnet test_robotparser > test_nntplib' If it were that easy! I can't isolate the bug. The only way I can reproduce it is by running the whole test suite with various random seeds. Then it takes about 6 hours until the crash occurs in one of those tests. The whole test suite takes about 24 hours. I could try to install libc-dbg though. -- ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12963] PyLong_AsSize_t returns (unsigned long)-1
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 stage: patch review status: open title: PyLong_AsSize_t returns (unsigned long)-1 type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23130/pylong_as_size_t.diff ___ Python tracker <http://bugs.python.org/issue12963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12965] longobject: documentation improvements
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 PyLong_AsLong() documentation states this explicitly. The patch clearly distinguishes between functions that duck type and functions that don't. - The patch replaces "is greater than *_MAX" instances with "out of bounds" to include the other error condition "is less than *_MIN". Additionally, the patch fixes comments in longobject.c that don't state the duck typing behavior. -- assignee: docs@python components: Documentation files: longobject-doc.diff keywords: patch messages: 143922 nosy: docs@python, mark.dickinson, skrah priority: normal severity: normal stage: patch review status: open title: longobject: documentation improvements type: feature request versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23133/longobject-doc.diff ___ Python tracker <http://bugs.python.org/issue12965> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12965] longobject: documentation improvements
Changes by Stefan Krah : -- assignee: docs@python -> mark.dickinson ___ Python tracker <http://bugs.python.org/issue12965> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12963] PyLong_AsSize_t returns (unsigned long)-1
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: open -> closed ___ Python tracker <http://bugs.python.org/issue12963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
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 the code allows for duck typing.
But the struct module (and by extension memoryview that must follow
the struct module) don't:
>>> import array, struct
>>> a = array.array('L', [1,2,3])
>>> class T(object):
... def __init__(self, value):
... self.value = value
... def __int__(self):
... return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])
>>> struct.pack_into('L', a, 0, T(200))
Traceback (most recent call last):
File "", line 1, in
struct.error: required argument is not an integer
>>>
I vastly prefer the struct module behavior. Since the code isn't executed
by any tests:
Is it really the intention for array to allow duck typing? The documentation
says:
"This module defines an object type which can compactly represent an array
of basic values: characters, integers, floating point numbers."
"Basic value" doesn't sound to me like "anything that has an __int__() method".
Also, consider this:
>>> sum([T(1),T(2),T(3)])
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'T'
>>> sum(array.array('L', [T(1),T(2),T(3)]))
6
--
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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.so.2 #1 0x40035a14 in __h_errno_location () from /lib/libpthread.so.0 #2 0x40a788dc in __libc_res_nsearch () from /lib/libresolv.so.2 #3 0x40a66e9c in _nss_dns_gethostbyname3_r () from /lib/libnss_dns.so.2 #4 0x40a670ac in _nss_dns_gethostbyname2_r () from /lib/libnss_dns.so.2 #5 0x40180480 in gaih_inet () from /lib/libc.so.6 #6 0x40181da8 in getaddrinfo () from /lib/libc.so.6 #7 0x406084a4 in socket_getaddrinfo (self=0x405d7bcc, args=0x4089a8b4, kwargs=0x0) at /home/user/mercurial-1.9.2/cpython/Modules/socketmodule.c:4787 #8 0x001ea384 in PyCFunction_Call (func=0x405da1f4, arg=0x4089a8b4, kw=0x0) at Objects/methodobject.c:84 #9 0x000a3634 in call_function (pp_stack=0xbeab7d1c, oparg=4) at Python/ceval.c:4000 #10 0x0009cab8 in PyEval_EvalFrameEx (f=0x407457b4, throwflag=0) at Python/ceval.c:2625 #11 0x000a0bfc in PyEval_EvalCodeEx (_co=0x405d6ab8, globals=0x40591a34, locals=0x0, args=0x408884dc, argcount=2, kws=0x408884e4, kwcount=0, defs=0x40512a20, defcount=2, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #12 0x000a3cfc in fast_function (func=0x405e30e4, pp_stack=0xbeab8068, n=2, na=2, nk=0) at Python/ceval.c:4098 #13 0x000a3838 in call_function (pp_stack=0xbeab8068, oparg=2) ---Type to continue, or q to quit--- at Python/ceval.c:4021 #14 0x0009cab8 in PyEval_EvalFrameEx (f=0x40888374, throwflag=0) at Python/ceval.c:2625 #15 0x000a0bfc in PyEval_EvalCodeEx (_co=0x4089d5d8, globals=0x4088d854, locals=0x0, args=0x404e2ac8, argcount=2, kws=0x405b43c8, kwcount=2, defs=0x4098fbd0, defcount=6, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #16 0x001c3060 in function_call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4) at Objects/funcobject.c:629 #17 0x0017f1a0 in PyObject_Call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4) at Objects/abstract.c:2149 #18 0x001a1a9c in method_call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4) at Objects/classobject.c:318 #19 0x0017f1a0 in PyObject_Call (func=0x4050b9d4, arg=0x404e2574, kw=0x409a98f4) at Objects/abstract.c:2149 #20 0x0004a6c0 in slot_tp_init (self=0x405ae504, args=0x404e2574, kwds=0x409a98f4) at Objects/typeobject.c:5431 #21 0x00037650 in type_call (type=0x40a31034, args=0x404e2574, kwds=0x409a98f4) at Objects/typeobject.c:691 #22 0x0017f1a0 in PyObject_Call (func=0x40a31034, arg=0x404e2574, kw=0x409a98f4) at Objects/abstract.c:2149 #23 0x000a46bc in do_call (func=0x40a31034, pp_stack=0xbeab84f0, na=1, nk=2) at Python/ceval.c:4220 #24 0x000a3858 in call_function (pp_stack=0xbeab84f0, oparg=513) at Python/ceval.c:4023 #25 0x0009cab8 in PyEval_EvalFrameEx (f=0x40558544, throwflag=0) at Python/ceval.c:2625 #26 0x000a0bfc in PyEval_EvalCodeEx (_co=0x40479d28, globals=0x403d5034, locals=0x403d5034, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #27 0x000916f4 in PyEval_EvalCode (co=0x40479d28, globals=0x403d5034, locals=0x403d5034) at Python/ceval.c:770 #28 0x000e0cb4 in run_mod (mod=0x37c8f8, filename=0x405028c8 "crash.py", globals=0x403d5034, locals=0x403d5034, flags=0xbeab8864, arena=0x2e5178) at Python/pythonrun.c:1793 #29 0x000e0a58 in PyRun_FileExFlags (fp=0x2ce260, filename=0x405028c8 "crash.py", start=257, globals=0x403d5034, locals=0x403d5034, closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1750 #30 0x000debcc in PyRun_SimpleFileExFlags (fp=0x2ce260, filename=0x405028c8 "crash.py", closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1275 #31 0x000dde68 in PyRun_AnyFileExFlags (fp=0x2ce260, filename=0x405028c8 "crash.py", closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1046 #32 0x000ff984 in run_file (fp=0x2ce260, filename=0x401fe028, p_cf=0xbeab8864) at Modules/main.c:299 #33 0x00100780 in Py_Main (argc=2, argv=0x401fc028) at Modules/main.c:693 #34 0x0001a914 in main (argc=2, argv=0xbeab8994) at ./Modules/python.c:59 -- ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1813] Codec lookup failing under turkish locale
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 versions. -- ___ Python tracker <http://bugs.python.org/issue1813> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 debian-arm when sched_setaffinity() is called *and* the program is linked to pthread: $ gcc -Wall -W -O0 -g -o crash crash.c $ ./crash $ $ gcc -Wall -W -O0 -g -o crash crash.c -pthread $ ./crash Segmentation fault (core dumped) # comment out: sched_setaffinity(0, size, cpusetp); $ gcc -Wall -W -O0 -g -o crash crash.c -pthread $ ./crash $ On Ubuntu all three cases run fine. Perhaps this is a bug in sched_setaffinity()? -- Added file: http://bugs.python.org/file23143/crash.c ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()
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'm attaching the non-crashing version. -- title: armv5tejl: random segfaults in getaddrinfo() -> armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np() Added file: http://bugs.python.org/file23145/pthread_nocrash.c ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()
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_setaffinity(syscall(SYS_gettid), size, cpusetp) crashes, too. This seems to be a violation of the man page, which states: "The value returned from a call to gettid(2) can be passed in the argument pid." Unless one uses a somewhat warped interpretation that linking against pthread constitutes "using the POSIX threads API". That would be the only loophole that would allow the crash. > 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. 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. > So I'd suggest closing this issue. I don't care strongly about using pthread_getaffinity_np(), but at least I'd like to skip the scheduling sections on arm-linux if they don't work reliably. -- ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
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/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
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: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> [PATCH] Configure should enable -fwrapv for clang ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
Changes by Stefan Krah : -- nosy: +a...@netbsd.org, skrah ___ Python tracker <http://bugs.python.org/issue11149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
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 "license" for more information. >>> 2**63 -9223372036854775808 >>> 2**64 0 >>> The patch is fine and I'm going to commit it tomorrow if there are no objections. -- priority: high -> critical ___ Python tracker <http://bugs.python.org/issue11149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12946] PyModule_GetDict() claims it can never fail, but it can
Stefan Behnel 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. -- ___ Python tracker <http://bugs.python.org/issue12946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
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_long test_long_future test_math test_random test_re test_strtod test_tokenize test_types test_xrange -- ___ Python tracker <http://bugs.python.org/issue11149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12720] Expose linux extended filesystem attributes
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/posixmodule.c:10045: error: ‘XATTR_SIZE_MAX’ undeclared (first use in this function) ./Modules/posixmodule.c:10045: error: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:10045: error: for each function it appears in.) ./Modules/posixmodule.c: In function ‘getxattr_common’: ./Modules/posixmodule.c:10083: error: ‘XATTR_SIZE_MAX’ undeclared (first use in this function) ./Modules/posixmodule.c: In function ‘posix_getxattr’: ./Modules/posixmodule.c:10101: warning: passing argument 3 of ‘getxattr_common’ from incompatible pointer type ./Modules/posixmodule.c: In function ‘posix_lgetxattr’: ./Modules/posixmodule.c:10119: error: ‘lgetxattr’ undeclared (first use in this function) ./Modules/posixmodule.c: In function ‘wrap_fgetxattr’: ./Modules/posixmodule.c:10129: error: too few arguments to function ‘fgetxattr’ ./Modules/posixmodule.c:10130: warning: control reaches end of non-void function ./Modules/posixmodule.c: In function ‘posix_setxattr’: ./Modules/posixmodule.c:10165: error: too few arguments to function ‘setxattr’ ./Modules/posixmodule.c: In function ‘posix_lsetxattr’: ./Modules/posixmodule.c:10190: warning: implicit declaration of function ‘lsetxattr’ ./Modules/posixmodule.c: In function ‘posix_fsetxattr’: ./Modules/posixmodule.c:10216: error: too few arguments to function ‘fsetxattr’ ./Modules/posixmodule.c: In function ‘posix_removexattr’: ./Modules/posixmodule.c:10239: error: too few arguments to function ‘removexattr’ ./Modules/posixmodule.c: In function ‘posix_lremovexattr’: ./Modules/posixmodule.c:10262: warning: implicit declaration of function ‘lremovexattr’ ./Modules/posixmodule.c: In function ‘posix_fremovexattr’: ./Modules/posixmodule.c:10285: error: too few arguments to function ‘fremovexattr’ ./Modules/posixmodule.c: In function ‘listxattr_common’: ./Modules/posixmodule.c:10327: error: ‘XATTR_LIST_MAX’ undeclared (first use in this function) ./Modules/posixmodule.c: In function ‘posix_listxattr’: ./Modules/posixmodule.c:10369: warning: passing argument 2 of ‘listxattr_common’ from incompatible pointer type ./Modules/posixmodule.c: In function ‘posix_llistxattr’: ./Modules/posixmodule.c:10385: error: ‘llistxattr’ undeclared (first use in this function) ./Modules/posixmodule.c: In function ‘wrap_flistxattr’: ./Modules/posixmodule.c:10394: error: too few arguments to function ‘flistxattr’ ./Modules/posixmodule.c:10395: warning: control reaches end of non-void function ./Modules/posixmodule.c: In function ‘all_ins’: ./Modules/posixmodule.c:11342: error: ‘XATTR_SIZE_MAX’ undeclared (first use in this function) make: *** [Modules/posixmodule.o] Error 1 program finished with exit code 2 elapsedTime=20.601350 -- nosy: +skrah status: closed -> open ___ Python tracker <http://bugs.python.org/issue12720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()
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 rather wait for review due to the slowness of the setup.] -- keywords: +patch Added file: http://bugs.python.org/file23154/arm_setaffinity.diff ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
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. -- ___ Python tracker <http://bugs.python.org/issue11149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12980] segfault in test_json on AMD64 FreeBSD 8.2 2.7
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, since it can't be reproduced. -- resolution: -> works for me stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12980> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
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() failures are fixed. I still get: test test_itertools failed -- Traceback (most recent call last): File "/usr/home/stefan/pydev/cpython/Lib/test/test_itertools.py", line 788, in test_islice self.assertEqual(len(list(islice(count(), 1, 10, maxsize))), 1) AssertionError: 3 != 1 test test_list failed -- Traceback (most recent call last): File "/usr/home/stefan/pydev/cpython/Lib/test/test_list.py", line 59, in test_overflow self.assertRaises((MemoryError, OverflowError), mul, lst, n) AssertionError: (, ) not raised But these are exactly the failures from 3.x. so they are probably unrelated to this issue (and they are "fixed" by -fwrapv). -- ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
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: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue11149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12985] Check signed arithmetic overflow in ./configure
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 Intel compiler is the odd one here. Even with -O0 this particular
overflow is undefined, but I can't remember seeing the specific
test failures from #12973. So the drawback is that the patch might
give false positives.
$ cat overflow_is_defined.c
#include
int overflow_is_defined(int x) {
if (x + 1000 < x)
return 0;
return 1;
}
int main() {
return overflow_is_defined(INT_MAX);
}
gcc-4.4.3
=
$ gcc -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ gcc -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c
overflow_is_defined.c: In function ‘overflow_is_defined’:
overflow_is_defined.c:3: warning: assuming signed overflow does not occur when
assuming that (X + c) < X is always false
$ ./overflow_is_defined || echo "undefined"
undefined
$ gcc -Wall -W -O2 -fwrapv -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$
clang-3.0
=
$ clang -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ clang -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ clang -Wall -W -fwrapv -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$
suncc-12.2
==
$ suncc -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ suncc -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$
icc-12.0.0
==
$ icc -Wall -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ icc -Wall -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$
--
files: configure_catch_overflow.diff
keywords: patch
messages: 144071
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Check signed arithmetic overflow in ./configure
type: feature request
Added file: http://bugs.python.org/file23160/configure_catch_overflow.diff
___
Python tracker
<http://bugs.python.org/issue12985>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12985] Check signed arithmetic overflow in ./configure
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-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
Changes by Stefan Krah : Added file: http://bugs.python.org/file23164/listobject_overflow.diff ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
Changes by Stefan Krah : Added file: http://bugs.python.org/file23165/itertools_overflow.diff ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
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://yarchive.net/comp/linux/signed_unsigned_casts.html Mark, did you write those rules down somewhere? I had to think a bit about the unsigned -> signed casts. -- ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12985] Check signed arithmetic overflow in ./configure
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 behavior in general. > BTW, I suspect that the reason there were no related test failures > with the Intel compiler is that most of the problems in the Python > code stem from multiplications rather than additions. Probably icc > isn't sophisticated enough to optimize those multiplication + division > checks away. Yes, I think that's it. > Seems like we should probably be looking for an icc flag that forces > wrapping on signed integer overflow. I didn't find any in the man page or search engines. > In the long run, it would still be good to eliminate the need > for fwrapv and the like; it can have a significant performance hit. I agree, but it's progressing quite slowly. ;) -- ___ Python tracker <http://bugs.python.org/issue12985> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
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 > 'implementation-defined' signal (C99 6.3.1.3p3). This seems > reasonable: I'm fairly sure that this provision is there mainly > for systems using ones' complement or sign-magnitude > representations for signed integers, and it's safe to assume > that Python won't meet such systems. This is what I was concerned about, but the assumption seems safe. -- ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12974] array module: deprecate '__int__' conversion support for array elements
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):
... return self.value
...
>>> struct.pack('P', IDX(9))
b'\t\x00\x00\x00\x00\x00\x00\x00'
>>>
--
___
Python tracker
<http://bugs.python.org/issue12974>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
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/issue1172711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12974] array module: deprecate '__int__' conversion support for array elements
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't recall which issue; Meador, do you remember?)
> So we added use of __index__ at that point.
Yes, I think that's #1530559, and the bug report was about PyCUDA. I can
see why 'bBhHiIlLqQ' allow __index__(), since they previously allowed
__int__().
I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
never allowed __int__(), but now index objects can be packed as pointers.
It isn't a big deal, I just have to know for features/pep-3118.
To illustrate, this is python2.5.0; INT is an object with an __int__() method:
'\x07\x00\x00\x00\x00\x00\x00\x00'
>>> struct.pack('P', INT(7))
Traceback (most recent call last):
File "", line 1, in
File "/home/stefan/hg/r25/Lib/struct.py", line 63, in pack
return o.pack(*args)
struct.error: cannot convert argument to long
>>>
--
___
Python tracker
<http://bugs.python.org/issue12974>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler
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: +skrah ___ Python tracker <http://bugs.python.org/issue12991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler
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 -> closed ___ Python tracker <http://bugs.python.org/issue12991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12974] array module: deprecate '__int__' conversion support for array elements
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://bugs.python.org/issue1172711#msg48086. But I think that the decision to accept __index__() for both signed and unsigned integer formats is good for consistency. For 'P' I'm not sure, but course it might be used in the wild by now. -- ___ Python tracker <http://bugs.python.org/issue12974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()
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 -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12998] Memory leak with CTypes Structure
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. -- nosy: +skrah resolution: -> out of date stage: -> committed/rejected status: open -> pending ___ Python tracker <http://bugs.python.org/issue12998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13002] peephole.c: unused parameter
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: peephole.c: unused parameter type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file23183/peephole_unused_parameter.diff ___ Python tracker <http://bugs.python.org/issue13002> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Changes by Stefan Krah : Added file: http://bugs.python.org/file23185/4492afe05a07.diff ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
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/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler
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 should be invoked as 'ld'. Several sites suggest that the HP compiler can be used a the linker front end (in the same manner as gcc). http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/r0007656.htm -- ___ Python tracker <http://bugs.python.org/issue12991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13014] Resource is not released before returning from the functiion
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 ___ Python tracker <http://bugs.python.org/issue13014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13014] _ssl.c: resource is not released before returning from the function
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/issue13014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0
Changes by Stefan Ring : -- nosy: +Ringding ___ Python tracker <http://bugs.python.org/issue8271> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler
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. The HP compiler might need similar options. -- ___ Python tracker <http://bugs.python.org/issue12991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13020] structseq.c: refleak
Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> structseq.c: refleak ___ Python tracker <http://bugs.python.org/issue13020> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] _ctypes.c: refleak
Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> _ctypes.c: refleak ___ Python tracker <http://bugs.python.org/issue13013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13017] pyexpat.c: refleak
Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> pyexpat.c: refleak ___ Python tracker <http://bugs.python.org/issue13017> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13018] dictobject.c: refleak
Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> dictobject.c: refleak ___ Python tracker <http://bugs.python.org/issue13018> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13017] pyexpat.c: refleak
Changes by Stefan Krah : -- components: +Extension Modules stage: -> patch review versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13017> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13018] dictobject.c: refleak
Changes by Stefan Krah : -- components: +Interpreter Core stage: -> patch review versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13018> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13014] _ssl.c: refleak
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/issue13014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13016] selectmodule.c: refleak
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.python.org/issue13016> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13015] _collectionsmodule.c: refleak
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.python.org/issue13015> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13019] bytearrayobject.c: refleak
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/issue13019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13002] peephole.c: unused parameter
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.org/issue13002> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
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/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1 > conftest.c -l nsl -lrt -ldld -ldl -lpthread >&5 Result of this test? -- nosy: +skrah ___ Python tracker <http://bugs.python.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] allow other rounding modes in round()
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). The version in http://hg.python.org/features/cdecimal#py3k-cdecimal is the same as the version that will be released as cdecimal-2.3 in a couple of weeks. Benchmarks for cdecimal-2.2 are over here: http://www.bytereef.org/mpdecimal/benchmarks.html#pi-64-bit Typically cdecimal is 2-3 times slower than floats. With further aggressive optimizations one *might* get that down to 1.5-2 times for a fixed width Decimal64 type, but this is pure speculation at this point. If you look at http://www.bytereef.org/mpdecimal/benchmarks.html#mandelbrot-64-bit , you'll see that the Intel library performs very well for that specific type. Exact calculations are performed in binary, then converted to decimal for rounding. Note that this strategy _only_ works for relatively low precisions. -- ___ Python tracker <http://bugs.python.org/issue13060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution
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 what will be released as cdecimal-2.3 in a couple of weeks. cdecimal-2.3 has a monumental test suite against *both* decimal.py and decNumber. The test suite no longer finds any kind of (unknown) divergence between decimal.py, cdecimal and decNumber. Tests for cdecimal-2.3 have been running on 6 cores for more than half a year. In short, review would be highly welcome. ;) -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
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 <http://bugs.python.org/issue13061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
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.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
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 *still* recommended to use -fwrapv. Could anyone test if the attached patch works for llvm-gcc? -- keywords: +patch Added file: http://bugs.python.org/file23265/llvm-gcc-fwrapv.diff ___ Python tracker <http://bugs.python.org/issue13061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
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 configure has not been fixed, this issue needs to stay open. -- components: +Build stage: -> needs patch status: closed -> open type: -> compile error versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13080] test_email fails in refleak mode
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://bugs.python.org/issue13080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13084] test_signal failure
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 "/home/stefan/cpython/Lib/test/test_signal.py", line 263, in check_wakeup
assert_python_ok('-c', code)
File "/home/stefan/cpython/Lib/test/script_helper.py", line 50, in
assert_python_ok
return _assert_python(True, *args, **env_vars)
File "/home/stefan/cpython/Lib/test/script_helper.py", line 42, in
_assert_python
"stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Traceback (most recent call last):
File "", line 41, in
File "", line 16, in check_signum
Exception: (10, 12) != (12, 10)
1 test failed:
test_signal
[103837 refs]
--
components: Tests
messages: 144718
nosy: skrah
priority: normal
severity: normal
status: open
title: test_signal failure
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13084>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13085] : memory leaks
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 status: open title: : memory leaks type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23281/pep-393-leaks.diff ___ Python tracker <http://bugs.python.org/issue13085> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13085] pep-393: memory leaks
Changes by Stefan Krah : -- title: : memory leaks -> pep-393: memory leaks ___ Python tracker <http://bugs.python.org/issue13085> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
