Stefan Krah added the comment:
Christian, you are also completely ignoring the original attack
of Anthony, so you are biased and there is no point continuing.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
I was the one being attacked in this issue, while releasing a zero
fault library whose release procedures resemble those found in
avionics software.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
It is instructive that ArchLinux quietly and professionally packaged
mpdecimal-2.5.0 hours after the release:
https://www.archlinux.org/packages/?sort==mpdecimal==
This is in stark contrast with Python-dev, where a maintainer of an
*experimental*
*nightly
Stefan Krah added the comment:
For clarification, the incident I referred to is entirely unrelated to *this*
issue: Of course Dino Viehland has been rational, friendly and competent.
I wanted to point out that people might have had a formative experience
*elsewhere
Stefan Krah added the comment:
Though code objects do not concern me directly, as the author of
memoryview I now concur with Inada-san that we should not support
hacks in the Python code base that benefit a single company.
--
___
Python tracker
Stefan Krah added the comment:
After seeing people from a certain company defend a bizarre and
broken stack with falsehoods, I apologize to Inada-san and now
assume that he had a similar experience.
--
nosy: +skrah
___
Python tracker
<ht
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
New changeset c84d3fe6b3301c7fd4a82e63fb4d545a7b9df84b by Miss Islington (bot)
in branch '3.9':
bpo-41161 Add news entry for libmpdec-2.5.0 (GH-21243) (#21244)
https://github.com/python/cpython/commit/c84d3fe6b3301c7fd4a82e63fb4d545a7b9df84b
Stefan Krah added the comment:
New changeset 1648c99932f39f1c60972bb114e6a7bd65523818 by Stefan Krah in branch
'master':
bpo-41161 Add news entry for libmpdec-2.5.0 (GH-21243)
https://github.com/python/cpython/commit/1648c99932f39f1c60972bb114e6a7bd65523818
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20395
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21243
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
It looks like a compiler bug (line numbers are after macro expansion):
#0 0x006ea678 in _PyEval_EvalFrameDefault (f=0x886d20
<_PyRuntime+352>, throwflag=-8) at Python/ceval.c:35554
#1 0x0057167b in _PyEval_EvalCodeWithName (_co=0x
Stefan Krah added the comment:
New changeset 604d95e235d86465b8c17f02095edcaf18464d4c by Lawrence D'Anna in
branch 'master':
bpo-41100: fix _decimal for arm64 Mac OS (GH-21228)
https://github.com/python/cpython/commit/604d95e235d86465b8c17f02095edcaf18464d4c
--
nosy: +skrah
Stefan Krah added the comment:
Yeah, I already felt a bit guilty about adding you -- it could be a compiler
bug or an actual overflow. My bet is also that the reordering exposes an
existing overflow. The reordering itself certainly looks correct to me.
When I have time, I'll try to look
Stefan Krah added the comment:
Since this is an ongoing problem: When I submitted the decNumber
patches to Cowlishaw, he asked me if I would be interested in
maintaining decNumber. I declined at the time due to time constraints.
Had I accepted, I'd control 2/3 of the decimal market now
Stefan Krah added the comment:
> You'll have to let the readers of this thread judge that for themselves.
Ask Cowlishaw or the mpfr developers to read this thread.
As for politeness, msg372581 was entirely polite and directly answered
by an inappropriate and petulant msg372584.
This no
Stefan Krah added the comment:
Major correction: Victor *did* ask for a news entry, but otherwise
I would not have added one.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
> The bot did ask you to add a news entry.
And I deliberately did not, out of politeness. Two release managers
were added and they did not ask.
> Other core developer go through great length to keep backwards compatibility
> for older or less comm
Stefan Krah added the comment:
Also note that people did not react at all to the fact that
coroutine storage was not thread safe across several releases.
No one asked for News entry.
But "breaking" a fringe distro seems to be a majo
Stefan Krah added the comment:
> I have opened bpo-41161 to address the issue.
Thanks, that is a more considerate approach, I'll add the note!
--
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
> This has nothing to do with your excellent fault rate (lack of any issues).
I sounds like that though for random people who read this issue and think
that Łukasz is the grand release manager who puts a person in his place.
That was incredibly inappropri
Stefan Krah added the comment:
> unreviewed and under-documented commit.
libmpdec has been one of the few zero fault areas of Python.
Please stop spreading FUD.
--
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
> Anthony noted a new failure related to your unreviewed and under-documented
> commit.
He claimed a failure in Ubuntu (in a manner that I took as petulant),
which isn't the case. It is a failure in a custom Ubuntu distro
that uses --with-system-li
Stefan Krah added the comment:
--with-system-libmpdec is a **long term** tool for distributions.
Pinning the version number ensures that they use the correct version.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
This is no release blocker. Version 2.5.0 has been in 3.9 for a long time, and
people should use the correct version.
--
priority: release blocker -> normal
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
You are talking to the author of libmpdec *and* the _decimal module.
Perhaps this problem has occurred to me, too:
$ diff -ur mpdecimal-2.5.0/libmpdec cpython-commit/Modules/_decimal/libmpdec/
Only in mpdecimal-2.5.0/libmpdec: .objs
Only in mpdecimal-2.5.0
Stefan Krah added the comment:
If Python is packaged with **system** libmpdec, you can only use
the official Ubuntu Python/libmpdec version combination.
Which are packaged by Matthias Klose, who is on the CC list here.
Otherwise, why use the system libmpdec at all and not the version
Stefan Krah added the comment:
Or is this CoC bait again?
--
___
Python tracker
<https://bugs.python.org/issue40874>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
Please name a buildbot that does not pass.
--
___
Python tracker
<https://bugs.python.org/issue40874>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Ubuntu is my main system, and it does not break the build.
If you use --with-system-libmpdec, you need to keep in sync with
the external libmpdec.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
cc Benjamin, in case he has any ideas: icc does not like the label
reordering in ceval.c, but that can be anything from an icc issue
to an actual overflow in ceval.c.
--
nosy: +benjamin.peterson
___
Python tracker
Stefan Krah added the comment:
icc does not like the label reordering from:
ddd1949fea59f256e51191540a4446f75ed608fa
This is one step further, but not much. Possibilities are still:
1) The reordering exposes an overflow.
2) The new ordering is not supported by icc, it introduces
Stefan Krah added the comment:
This appears to be fixed now.
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39701>
___
___
Python-
Stefan Krah added the comment:
A very brief guide for all users of --with-system-libmpdec:
Python 3.7 and Python 3.8 both require the release with this sha256sum:
83c628b90f009470981cf084c5418329c88b19835d8af3691b930afccb7d79c7
mpdecimal-2.4.2.tar.gz
Python 3.9 requires the release
Stefan Krah added the comment:
New changeset 119de0eba839993cf6a909dba5d60202ad5566d6 by Miss Islington (bot)
in branch '3.9':
bpo-40874 Update the required libmpdec version for the decimal module
(GH-21202)
https://github.com/python/cpython/commit/119de0eba839993cf6a909dba5d60202ad5566d6
Stefan Krah added the comment:
New changeset 8bea91b5e9ea07ca93958e131b436024f0b1b1cf by Stefan Krah in branch
'master':
bpo-40874 Update the required libmpdec version for the decimal module (GH-21202)
https://github.com/python/cpython/commit/8bea91b5e9ea07ca93958e131b436024f0b1b1cf
Change by Stefan Krah :
--
pull_requests: +20355
pull_request: https://github.com/python/cpython/pull/21202
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
C99, 6.3.1.4 Real floating and integer:
"""
When a value of integer type is converted to a real floating type, if the value
being
converted can be represented exactly in the new type, it is unchanged. If the
value being
converted is in the
Stefan Krah added the comment:
Is it a bug in float.__trunc__()? It seems to me that the detailed comment
accounts for case of rounding up.
That's why < is used instead of <=.
--
nosy: +skrah, tim.peters
___
Python tracker
Stefan Krah added the comment:
"""
* Doc/c-api/buffer.rst: the table with ".. c:macro:: PyBUF_INDIRECT" is wrong.
Sphinx fails because PyBUF_SIMPLE is declared twice.
=> use ":c:macro:`PyBUF_INDIRECT`" instead
"""
Hmm, grep shows:
Stefan Krah added the comment:
Thanks!
Ha, it turns out that c99_r has excellent C99 compliance. :)
> Variable arguments macro RAISE_SYNTAX_ERROR was invoked with an empty
> variable argument list.
Totally legit, we should use xlc (at least the front end) more often.
So maybe ou
Stefan Krah added the comment:
I've tested the MSVC _snprintf extremely extensively in _decimal and never had
a problem.
--
___
Python tracker
<https://bugs.python.org/issue36
Stefan Krah added the comment:
Can't we just use #ifndef __cplusplus instead of changing the function?
I don't think anyone compiles the affected files with a C++ compiler.
There are many areas in Include/* that fail with C++, e.g. isnan() with
-std=c++11.
--
nosy: +skrah
Stefan Krah added the comment:
So it would still be interesting to see what happens if you compile
libmpdec with c99_r (emphasis mine):
"""
This command supports all ISO
C99 language features, but does
not support IBM language
extensions. Use this invocation for
*stri
Stefan Krah added the comment:
Thanks for this information. The buildbot, however, fails to compile
C99 extern inline functions. Example:
ld: 0711-317 ERROR: Undefined symbol: .mpd_issnan
I understand the C99 extern inline feature like in this explanation:
https://www.greenend.org.uk/rjk
Stefan Krah added the comment:
> The first warning line in the initial message of this bug report tries to
> allocate 872 petabyte.
Yes, that's for systems like Linux where you never know what overallocation is
going to permit and subsequently freeze the system.
Special casing
Stefan Krah added the comment:
And indeed, with the new decimal MAX_PREC feature, you should see
the misguided diagnostic as well on OS X:
>>> from decimal import *
>>>
>>> c = getcontext()
>>> c.prec = MAX_PREC
>>> Decimal(4).sqrt()
Decimal(
Stefan Krah added the comment:
But if malloc_print_configure() is not a public API, it should probably not be
used.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
No, it does not cause real issues. Adding this feature would just suppress
chatty diagnostics like this one, which are a bit unfriendly:
>>> [0] * 1
python3(36633,0x110c08dc0) malloc: can't allocate region
:*** mach_vm
Stefan Krah added the comment:
Changing the title to get more input from others.
--
title: test_decimal.CWhitebox.test_maxcontext_exact_arith() shows "malloc:
can't allocate region" on MacOS -> OS X: malloc(): set default diagnostics to
DEBUG_W
Stefan Krah added the comment:
I would probably put all that code in a separate function like
init_darwin_libc(), and call init_darwin_libc() in pymain_init().
The real fun will start when we figure out which OS X versions
support this feature. I hope we have a buildbot for each
Stefan Krah added the comment:
> What about overriding the default to DEBUG_WRITE_ON_CRASH if
> MallocDebugReport is not set?
That sounds like a very good compromise!
--
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
I have two observations:
First, I think that the default DEBUG_WRITE_ALWAYS, which is the cause
of this issue, is not C standard conforming -- The standard does not
permit implementation defined diagnostics (global side effects!) on a
completely normal
Stefan Krah added the comment:
Thanks for checking, it's a pity that os.putenv() does not work.
There's a global variable malloc_logger that is set from the
environment on startup:
https://opensource.apple.com/source/libmalloc/libmalloc-53.1.1/src/malloc.c
It seems to be always checked
Stefan Krah added the comment:
"squashing the remark" means suppressing the message from malloc().
I would really like it if the test could be executed by default though.
Looking at:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man
Stefan Krah added the comment:
I'm aware of what -fwrapv does, it is a long standing issue in Python.
I didn't try to find the exact location of overflow, since we also use -fwrapv
for gcc.
It is also possible that giving -fwrapv to icc disables another optimization
that is the actual
Stefan Krah added the comment:
The annoying "error" looks the same as #5614, which was closed as "won't fix".
Is this the only place in the test suite now? If it is, I'm okay with
squashing the remark.
--
nosy: +skrah
v
Stefan Krah added the comment:
Yes, the generated Python crashes (as the link I gave shows). I'm using the
command line, so I can't be of any assistance with Parallel Studio XE.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue40923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
It would be easier to understand this issue if you provide the exact
command line.
icc also segfaults without -fwrapv, see #40223, so that may be the
cause here, too.
--
nosy: +skrah
___
Python tracker
<ht
Stefan Krah added the comment:
s/icc/Python compiled with icc/
--
___
Python tracker
<https://bugs.python.org/issue40923>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
The 3.9 change (see #40874) works successfully on all buildbots, except for the
32-bit xlc bot which should use c99_r.
Additionally, it has been tested with the latest gcc/clang/icc/cl.exe, static
analyzers and clang-tidy.
It survives brute force allocation
Stefan Krah added the comment:
New changeset 0f5a28f834bdac2da8a04597dc0fc5b71e50da9d by Stefan Krah in branch
'3.8':
[3.8] Revert bpo-39576: Prevent memory error for overly optimistic precisions
(GH-20747)
https://github.com/python/cpython/commit/0f5a28f834bdac2da8a04597dc0fc5b71e50da9d
Stefan Krah added the comment:
New changeset 22faf6ad3bcc0ae478a9a3e2d8e35888d88d6ce8 by Stefan Krah in branch
'3.7':
[3.7] Revert bpo-39576: Prevent memory error for overly optimistic precisions
(GH-20748)
https://github.com/python/cpython/commit/22faf6ad3bcc0ae478a9a3e2d8e35888d88d6ce8
Change by Stefan Krah :
--
pull_requests: +19953
pull_request: https://github.com/python/cpython/pull/20748
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +19952
pull_request: https://github.com/python/cpython/pull/20747
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset 9bd891920a5186b7d02281ea9966225efa0ceba1 by Stefan Krah in branch
'3.7':
[3.7] Revert bpo-39576: docs: set context for decimal arbitrary precision
arithmetic (GH-20746)
https://github.com/python/cpython/commit
Stefan Krah added the comment:
New changeset 32c1fb07e6f2ded90e5dd24d4b46b7aa7a795d2e by Stefan Krah in branch
'3.8':
[3.8] Revert bpo-39576: docs: set context for decimal arbitrary precision
arithmetic (GH-20745)
https://github.com/python/cpython/commit
Change by Stefan Krah :
--
pull_requests: +19951
pull_request: https://github.com/python/cpython/pull/20746
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +19950
pull_request: https://github.com/python/cpython/pull/20745
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset c0b79450bc9e93105799528151c48d25af8240a3 by Stefan Krah in branch
'3.7':
[3.7] Revert bpo-39576: Clarify the word size for the 32-bit build. (GH-20744)
https://github.com/python/cpython/commit/c0b79450bc9e93105799528151c48d25af8240a3
Stefan Krah added the comment:
New changeset 706de4e5a4b21880c67f6b90e3a2147a258d6fc5 by Stefan Krah in branch
'3.8':
[3.8] Revert bpo-39576: Clarify the word size for the 32-bit build. (GH-20743)
https://github.com/python/cpython/commit/706de4e5a4b21880c67f6b90e3a2147a258d6fc5
Change by Stefan Krah :
--
pull_requests: +19949
pull_request: https://github.com/python/cpython/pull/20744
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +19948
pull_request: https://github.com/python/cpython/pull/20743
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
I think I'm going to revert this for 3.7 and 3.8 -- not because of xlc (it is
almost certainly a compiler or missing flag error), but because coordination
with the Linux distributions is a mess, see #40874.
I really want the system libmpdec to be the same
Stefan Krah added the comment:
> It's not a regression. It's just that bpo-40521 helped Valgrind to detect
> such bug :-)
Yes, I suspected that previously reachable global objects were just unreachable
after the new free lists. Thanks for t
New submission from Stefan Krah :
I'm opening a separate issue to prevent #40521 from getting too big.
Lists and tuples sometimes leak (starting 69ac6e58f and later):
==1445== 56 bytes in 1 blocks are definitely lost in loss record 1,542 of 4,898
==1445==at 0x4C2DE56: malloc
New submission from Stefan Krah :
Also in test_decimal, there's a small leak here:
==10040== 24 bytes in 1 blocks are definitely lost in loss record 549 of 5,095
==10040==at 0x4C2DE56: malloc (vg_replace_malloc.c:299)
==10040==by 0x643B33: fstring_compile_expr (parse_string.c:594
New submission from Stefan Krah :
./configure --with-valgrind:
Objects/unicodeobject.c: In function ‘unicode_release_interned’:
Objects/unicodeobject.c:15672:26: error: lvalue required as left operand of
assignment
Py_REFCNT(s) += 1;
^
Objects
New submission from Stefan Krah :
>From test_decimal:
test_xor (test.test_decimal.PyIBMTestCases) ... ==17597== Invalid read of size 1
==17597==at 0x64A7E2: newline_in_string (pegen.c:940)
==17597==by 0x64A84E: bad_single_statement (pegen.c:958)
==17597==by 0x64A
Stefan Krah added the comment:
New changeset 83bff88b4b16fb30491faa9263bbd6f3df4bab56 by Miss Islington (bot)
in branch '3.9':
bpo-40874: Update to libmpdec-2.5.0 (GH-20652)
https://github.com/python/cpython/commit/83bff88b4b16fb30491faa9263bbd6f3df4bab56
New submission from Stefan Krah :
There appears to be an xlc buildbot with libmpdec failures.
libmpdec uses C99 extern inline semantics. From the brief period that I had
access to xlc I remember that xlc was quite picky about C99.
Actually all of Python uses C99. So I think xlc_r needs
Change by Stefan Krah :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue40874>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
It finally went through after Travis-CI hanging for about an hour.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
New changeset 087d612efebe7c64e5f079b07e0454111859830e by Stefan Krah in branch
'master':
bpo-40874: Update to libmpdec-2.5.0 (GH-20652)
https://github.com/python/cpython/commit/087d612efebe7c64e5f079b07e0454111859830e
New submission from Stefan Krah :
Again code coverage prevents the merge button from going green:
https://travis-ci.org/github/python/cpython/jobs/695095365
"The job exceeded the maximum time limit for jobs, and has been terminated."
Why can this not run on buildbot.
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +19872
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20652
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Krah :
Synopsis: There are no relevant new features for _decimal, but it would be too
much work/error prone to have divergent code in libmpdec-2.5.0 and Python 3.9,
especially for the Linux distributions.
I'll release libmpdec-2.5.0/libmpdec++-2.5.0 in a month
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue40244>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Since I just had a similar incident with the Intel compiler, I just
want to point out that compiling CPython still requires -fwrapv.
I've mentioned this before in AIX issues, and no one has pointed
out the corresponding xlc flag.
https://gcc.gnu.org/legacy-ml
New submission from Stefan Krah :
50e6e991781db761c496561a995541ca8d83ff87 causes or exposes a
leak. Possibly the leak was there before but showed up under
"still reachable".
Now it is "definitely lost", so tstate->interp->ceval.pending
needs to be cleaned up.
==11
New submission from Stefan Krah :
Newer icc version require -fwrapv:
https://software.intel.com/en-us/forums/intel-c-compiler/topic/849064
--
components: Build
messages: 365976
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add -fwrapv for new icc
Stefan Krah added the comment:
You can also set the decimal.FloatOperation trap to avoid accidental
errors:
>>> from decimal import *
>>> c = getcontext()
>>> Decimal(4.6) * 100
Decimal('459.9644728632120')
>>> c.traps[FloatOperation] = True
&g
Stefan Krah added the comment:
Has anything emerged xlc-wise? Traceback, does it work --without-pymalloc?
I have the feeling that (in many OSS projects) the more complex xlc
issues never get resolved after the initial report.
So I'm contemplating to do the same as
https
Stefan Krah added the comment:
> Or maybe _decimal_state_global was used in "hot code".
Yes, _decimal has problems here that most modules don't have.
Modules like atexit are obviously fine. :)
I just posted it as an example why one should be a bit cautious.
> The PEP 573
Stefan Krah added the comment:
> Wouldn't having less static types slow down startup time?
Yes, and not only startup time:
https://bugs.python.org/issue15722
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
The lower MAX_PREC for 32-bit could be the reason.
On the other hand, historically, suncc and xlc have had a lot of
problems with the 64-bit build. The winner is suncc, which seriously
miscompiled libmpdec without a whole litany of flags:
https
Stefan Krah added the comment:
Since xlc has elementary bugs like
https://github.com/openssl/openssl/issues/10624
it may be worth checking out if this is an optimizer bug with -q64.
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
I think this issue should be about fixing the tests so that people
looking at the sanitizer buildbots can move on.
GH-18969 fixes "?" and "!?", which clearly used wrong
semantics with the new compiler behavior. This should be an
uncontrov
Stefan Krah added the comment:
> So it's clear that something has to change. IMO, preserving (2) and relaxing
> (1) is the more useful choice.
But not in this issue I think. GH-18969 is a minimal change that
*removes* UB for the standard sizes.
UB for the native type is a
Stefan Krah added the comment:
Sorry, I'm reacting like Granlund now and close. These discussions
lead nowhere.
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issu
101 - 200 of 3373 matches
Mail list logo
