Changes by Stefan Krah <ste...@bytereef.org>:
--
versions: -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25928>
___
Stefan Krah added the comment:
On Wed, Dec 23, 2015 at 09:01:22PM +, John Walker wrote:
> Stefan, _int is a slot in Lib/_pydecimal.py. It should be defined on python
> 3.5 and tip, unsure about other versions.
>
> Python 3.5.1 (default, Dec 7 2015, 12:58:09)
> [GCC 5.2.0]
Stefan Krah added the comment:
Let's re-target this issue:
Implementing as_integer_ratio() sounds reasonable, but let's hope
people won't try to convert Decimal('1E+99').
Mark, was there perhaps a reason not to add the method?
--
assignee: -> skrah
n
Stefan Krah added the comment:
The current issue description should have been fixed by #25827.
Is the segfault in test_re still happening?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Stefan Krah:
Zachary in #24999:
"If that's the case, would anyone (in particular, Steve, Tim or Tim) mind if we
just made the default (for MSVC as well as ICC) /fp:strict? It would be much
easier to just change the global default than to try to either make it set
Changes by Stefan Krah <ste...@bytereef.org>:
--
title: ICC compiler: ICC treats denormal floating point numbers as 0.0 ->
Segfault in test_re.test_sre_character_class_literals() when Python is compiled
by ICC
___
Python tra
Stefan Krah added the comment:
No, the regular build uses the libmpdec that is shipped with
Python. The external libmpdec.so only comes into play if you
compile --with-system-libmpdec.
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
I see, thanks. I've opened #25934 to keep the issues separate.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Usually unaligned accesses are believed to carry a big performance
penalty, though rumor has it that for the latest generation of CPUs
this is no longer an issue.
--
nosy: +skrah
___
Python tracker <
Stefan Krah added the comment:
The compiler does not perform type checking. These are
type *annotations* for third party tools like Mypy.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
> Py_ssize_t ob_array[1] Py_VARIABLE_SIZE; /* Looks weird and confusing */
Yes, I dislike that, too. The question is why gcc has supported
the "struct hack" for more than 20 years but needs an annotation
just for MPX.
Is the annotation also neede
Stefan Krah added the comment:
I think you may have meant Eli Bendersky -- I'm not an elementree
expert (Eli, I'm adding you back just to clear this up).
--
nosy: +eli.bendersky
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
New submission from Stefan Krah:
memory_hex from #9951 fails for non-contiguous buffers.
--
assignee: skrah
files: memhex.diff
keywords: patch
messages: 254454
nosy: skrah
priority: normal
severity: normal
status: open
title: Fix memory_hex (#9951) for non-contiguous buffers
type: crash
Stefan Krah added the comment:
It's a Linux issue. Disable overcommitting of memory (at your own
peril) or set user limits (for example with djb's softlimit), then
the process will be killed instead of freezing the machine.
--
nosy: +skrah
___
Python
Stefan Krah added the comment:
I had a similar issue with ucspi-ssl that was fixed by following
the O'Reilly book's recommendations w.r.t WANT_READ/WANT_WRITE
with non-blocking sockets to the letter.
The recommendations are quite complex since apparently
WANT_READ/WANT_WRITE mean different
Stefan Krah added the comment:
> It looks to me that all issues are related to floating points.
You need to compile with "-fp-model strict" or the Windows
equivalent (I think "-fp-model precise").
--
___
Python tracker <rep
Stefan Krah added the comment:
If anyone worries that "-fp-model strict" will slow
things down: In the Python context these settings have
no measurable impact: A while ago I tested setting/restoring
the control word *for every operation*, and even that did
not have
Stefan Krah added the comment:
Thank you!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25558>
___
___
Python-bugs-list
Stefan Krah added the comment:
Serhiy, could you please not change stuff that I maintain? I know
you have the best intentions, but I really don't like these kinds
of changes (just like you don't like trailing whitespace :).
--
nosy: +skrah
Stefan Krah added the comment:
Victor, I'm adding you just in case this also affects your
optimizer (like #2).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +haypo
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24623>
___
__
Stefan Krah added the comment:
Thanks, no big problem. The thing is that the parts I wrote
(Modules/_decimal/*, Objects/memoryobject.c, Modules/_testbuffer.c)
have been audited rather heavily and have 100% code coverage
with a privately maintained patch that inserts allocation
failures
Stefan Krah added the comment:
The MASK idiom is nice and I think it's good to be exposed to
it from time to time.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
First of all, the premise "exports > 0" in your example looks wrong
to me. The deallocation process for the first view should start precisely when
it no longer has any exports.
In fact, the check for "exports > 0" is for the ca
Changes by Stefan Krah <ste...@bytereef.org>:
--
assignee: -> skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25524>
___
__
New submission from Stefan Krah:
See for example #25498.
--
messages: 253787
nosy: skrah
priority: normal
severity: normal
status: open
title: Add PyMemoryView_FromObjectWithFlags()
versions: Python 3.6
___
Python tracker <rep...@bugs.python.
Stefan Krah added the comment:
Florin, thanks for the explanation. I'd suggest to wait until
the mpx support is stable in gcc.
Some security features in gcc never take off (-ftrapv is broken,
libmudflap is deprecated, ...) so it would be nice to have some
reassurance
Stefan Krah added the comment:
The "chained memoryviews" you refer to are a hack and simply
aren't supported. Please stop spreading FUD.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Stefan Krah added the comment:
> But I think there should be some way of guaranteeing that a memoryview will
> not try to access memory which has already been freed.
Unless the "buffered *self" parameter in _buffered_raw_read() is
made a full PEP-3118 exporter, I'm not s
Stefan Krah added the comment:
The current hack isn't necessary. I didn't review eryksun's patch
in depth, but on the surface it looks good.
I don't think the other issues you mentioned are closely related:
The cause here is that the obj fields of both the second memoryview
and the second mbuf
Stefan Krah added the comment:
Per the docs the readonly flag must be consistent for all consumers,
so checking for writability after getting the view should be okay in
principle.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Stefan Krah added the comment:
If memoryview B is created from memoryview A, then B must be
registered with the same ManagedBuffer as A, otherwise the
whole scheme breaks down (PyMemoryView_FromObject() performs
this check).
PyMemoryView_FromBuffer() is really a legacy function that
should
Stefan Krah added the comment:
We should ultimately do something like I suggested in msg235256.
Everything else is a hack (N.B.: the issues that 1da9630e9b7f
tried to fix were also hacks, so it isn't really the fault of
that commit).
--
nosy: +skrah
Stefan Krah added the comment:
> The Python MPX binary will be built with –O0 because other optimization
> levels will change instruction order and cause crashes, making it useful for
> debugging purposes.
I've trouble understanding this: Is the gcc mpx feature not stable?
Stefan Krah added the comment:
Adjusting the estimate at runtime sounds good to me.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Try setting the stack size to 8MB (the default on Linux) in login.conf.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
It's not noise, we also have problems on Windows with test_json.
In theory we should set Py_DEFAULT_RECURSION_LIMIT in Python/ceval.c
to appropriate values for the default OS stack sizes in order to get
a proper RuntimeError instead of a segfault.
For OpenBSD
Stefan Krah added the comment:
Or did you want to compute it at runtime? Actually, why not?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
The ratio (1000/8MB) seems to be stable on Linux. Perhaps we could
write a getrlimit program for ./configure to get the stack size and
adjust the recursion limit to keep the ratio the same.
It's just an estimate of course
Stefan Krah added the comment:
> Third party modules might need patching to work with MPX...
If the flags go into CFLAGS, these modules won't compile with
distutils. Perhaps we should also add LDFLAGS_NODIST, if that
would solve your prob
New submission from Stefan Krah:
I think tokenize.py needs to be updated to support f-strings.
BTW, the f-string implementation seems to be incredibly robust. Nice work!
--
components: Library (Lib)
messages: 252274
nosy: eric.smith, skrah
priority: normal
severity: normal
stage
Stefan Krah added the comment:
Wouldn't setting CFLAGS be sufficient?
./configure CFLAGS="-fcheck-pointer-bounds -mmpx"
Otherwise we could also add --with-stack-protector and --with-fortify-source
and others. I'm not sure if we should add a special --with*
option for ever
Stefan Krah added the comment:
> Whether the hardware is MPX enabled is irrelevant for the build process.
The build process is only one part of the equation. Compilers do have
bugs (Python has been affected by gcc, Visual Studio and suncc bugs),
and we should test the actual generated
Stefan Krah added the comment:
> It's possible that Python needs to be built with special options to allow
> additional malloc space (-bmaxdata:0xN000).
It seems to be the case, see Misc/README.AIX. This could explain the
MemoryErrors, but not the segfaults.
Are computed-gotos
Stefan Krah added the comment:
Static types leak memory on finalization, see PEP 3121. Normally it
does not matter, but you see it when embedding Python.
PEP 3121 isn't widely implemented because a) it complicates the
code for large modules and b) there are some performance issues
Stefan Krah added the comment:
If you have time, you could use an explicit seed (and gdb):
# test_email segfault:
./python -m test -j 1 -u all -W --randseed 5634141
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
And the segfaults are apparently somewhat random. This is beginning
to look like an issue unrelated to decimal that was perhaps recently
introduced (in which case "hg bisect" would be the fastest
way to debug).
http://buildbot.python.org/all/builders/P
Stefan Krah added the comment:
I've checked: test_decimal does not require abnormal amounts of
memory or stack. On Linux/x86 a stack size of 256 (default 8192)
is sufficient, and memory requirements aren't that high.
We assumed that there is some memory limit on the buildbot, since
in a later
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25300>
___
__
Stefan Krah added the comment:
In principle adding the option is fine, but do we have a buildbot
with a Skylake processor? We have lots of options that are untested
and that break periodically.
--
nosy: +zach.ware
___
Python tracker <
Stefan Krah added the comment:
Usually these segfaults are toolchain bugs (I've had at least 8,
including gcc, suncc, libc...).
Just a couple of observations:
- The bot builds with -DCONFIG_32=1 -DANSI=1 despite being PPC64.
- When we had an AIX snakebite machine, the xlc compile worked
Stefan Krah added the comment:
> There are similar issues with Decimal.from_float() (C implementation only),
> chain.from_iterable(), epoll.fromfd() and kqueue.fromfd(). All these
> alternative constructors don't call __new__ or __init__.
Could you create new issues? I need
Stefan Krah added the comment:
Regarding volatile: gcc/clang seem to honor *some* changes to
the control word. At least in libmpdec both compilers have
always left the settings 80bit-prec/ROUND_CHOP intact, even
though it's not the default.
Let's rewrite Python in asm to avoid these issues
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +loewis, skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25124>
___
_
Stefan Krah added the comment:
In theory we should set FENV_ACCESS whenever the control word is
changed (C99):
"If part of a program tests floating-point status flags, sets
floating-point control modes, or runs under non-default mode
settings, but was translated with the
Stefan Krah added the comment:
Ok, clang does not support it either:
https://llvm.org/bugs/show_bug.cgi?id=10409
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Yes, errno should always be cleared before use (in C99 at least,
not sure what the crt does).
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Clearing is easy: errno = 0; :)
C library functions are not supposed to set errno to 0 by
themselves (C99: paragraph 7.5).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Steve, sorry if I misunderstand you: My point (and eryksun's)
was that errno is currently not cleared before the call to
format_time() in
Modules/timemodule.c:657
I didn't look at this issue in depth, just pointing out a
possible cause
New submission from Stefan Krah:
If a type scheme is instantiated, should the type variables in the
class body be substituted? This is an example (typed by hand on
a locked down Windows machine, may contain errors):
alpha = TypeVar('alpha')
beta = TypeVar('beta')
class ABTuple(Generic[alpha
Stefan Krah added the comment:
I think the issue can be closed (after updating "what's new").
Even if we wanted to keep backwards compatibility, it's too
late now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Stefan Krah added the comment:
See:
https://docs.python.org/3/reference/lexical_analysis.html#blank-lines
--
assignee: -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python, skrah
resolution: -> not a bug
stage: -> resolved
status: open ->
Stefan Krah added the comment:
According to the human readable grammar in the docs
https://docs.python.org/3/reference/expressions.html#calls
I'd say this was a bug that is now fixed in 3.5. The call should
either take a single unparenthesized generator expression or an
argument_list (which
Stefan Krah added the comment:
Thanks, I've contacted Robert.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24999>
___
___
Pyth
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +larry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25027>
___
__
Stefan Krah added the comment:
Yes, according to C99 the shift is undefined:
6.5.7:
"If the value of the right operand is negative or is greater than
or equal to the width of the promoted left operand, the behavior
is undefined."
--
Stefan Krah added the comment:
If the scientific stack is unusable, I think this should be a release
blocker.
--
nosy: +skrah
priority: normal -> release blocker
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
Perhaps the stack overflow hypothesis applies here, too.
You could try changing Py_DEFAULT_RECURSION_LIMIT in ceval.c
to lower values.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Is Python-core built with /MD? I cannot see the flags in the buildbot
logs.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
It seems to be /MTd. Sorry for the noise (and yay! for horizontal scrolling :).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
The reason I asked: We had issues where extension modules linked
against a different CRT had isolated locale settings from the
interpreter, i.e., changes made by the module would not be seen
by the interpreter.
I don't know if this is still an issue with the new
Stefan Krah added the comment:
Visual studio apparently has the option /F to set the stack size.
Maybe ICC has one, too.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
The buildbot segfaults all over the place, also in test_tokenize
and test_json:
http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/89/steps/test/logs/stdio
Running the tests under the VS debugger is probably the fastest
Stefan Krah added the comment:
Just (hopefully) for extra clarity: As you mentioned, the 3.6 patch
is perfect for 3.5, too. The reason why 3.5 was brought up is to ask
Larry, our release manager, to allow it already for 3.5.
Technically it's an enhancement/new feature, but practically
Stefan Krah added the comment:
I don't think we should provide any performance guarantees in the
Makefile. +1 for not special-casing x86 (does it include amd64?).
As I understood, Antoine was not talking about a unified patch
but about applying the 3.6 patch to 3.5 right away
Stefan Krah added the comment:
Hmm, I don't see a 32-bit ICC buildbot. This problem can only occur
on 32-bit with -DPPRO defined.
Please go ahead and commit the patch. The inline asm
miscompilation problem I mentioned earlier was solved in
12.0 (I think), so let's just assume it's gone
Stefan Krah added the comment:
We can always blame any fallout on ICC. ;)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Are you sure that you always tested the 32-bit build, also with ICC 15.0?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Also note that ICC <= 11.0 did not handle __GNUC__ inline asm
correctly, see the comment:
Modules/_decimal/libmpdec/umodarith.h:391
I've disabled asm for Linux/ICC in setup.py.
I don't know how the situation is with MASM inline asm, but I'd
recommend to t
Stefan Krah added the comment:
Steve: What do you mean by "global option"? The C99 standard says
that FENV_ACCESS (if set), is active until the end of the translation
unit (here: mpdecimal.c).
--
___
Python tracker <rep...@bugs.pyth
Stefan Krah added the comment:
On Linux ICC has something like "fast-math" by default. The situation
is a bit annoying: On Unix ICC defines __GNUC__, but does not really
have all the features. Here ICC defines _MSC_VER, but does not behave
like cl.exe.
[I know it's a hard problem t
Stefan Krah added the comment:
If "#pragma float_control(precise, push)" is exactly the MSVC default
then I'm fine with putting it on top of FENV_ACCESS.
There's nothing speed sensitive going on here: In the 32-bit build
the x87 FPU is used for modular multiplication of integers
Stefan Krah added the comment:
I guess that in the test case the stop parameter is set to 4 in
deque_index(), but it should be clamped to 3.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24913
Stefan Krah added the comment:
My initial reaction is that the default should be optimized for
short build times. I would not want to type disable-profile-opt
every time I'm running the tests.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
Yacc uses low to high.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24921
___
___
Python-bugs-list
Stefan Krah added the comment:
Actually, for ecryptfs we could just check for ~/.ecryptfs and
then use /tmp.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24831
Stefan Krah added the comment:
Yes, the current scheme is probably good for easy buildbot cleanup.
Maybe we can blacklist some filesystems to choose the temporary directory.
If that's easily possible, it would be a good solution at least
for ecryptfs.
I've removed ecryptfs from my setup
Stefan Krah added the comment:
It's very likely an I/O issue. There are several large file
tests that run even if 'largefile' is disabled. It already
helps a lot if the following tests are decorated with
requires_resource('largefile'):
test_mmap: class LargeMmapTests()
test_io: large_file_ops
Stefan Krah added the comment:
I don't know whether this is worth reopening, but the ecryptfs
performance is still very poor on my Lenovo T400 (see #24831).
For most people an extra option for choosing the tmpdir
would not help, since they'd simply blame the hardware
or the test suite
Stefan Krah added the comment:
Thanks, this clears up the mystery! -- I made the mistake of choosing
the eCryptfs-homedir option when installing Ubuntu, so now I have eCryptfs on
top of LVM on top of full-disk encryption.
So I can't create sparse files in my home directory, but I *can*
create
Stefan Krah added the comment:
Done. Thanks for the patch.
--
components: +Interpreter Core
resolution: - fixed
stage: patch review - resolved
status: open - closed
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
I would commit this, except that I'm not too happy with the use of
the term bytes-like in general. Yesterday I mistyped this:
import ctypes
x = ctypes.c_double
m = memoryview(x)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError
Stefan Krah added the comment:
For end users it's probably adequate. But several committers find
the term confusing (msg236283, msg188484). :)
Anyway, I'm going to commit this since it adds clarity.
--
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
Martin, thanks for the patch!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
versions: +Python 3.6 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
New submission from Stefan Krah:
On my machine (Lenovo T400, Linux) the load average during running
the 2.7 test suite is about 0.5 (with some exceptions like test_io).
The system is still usable even during test_io.
In 3.6 the load average is 2.0, with some tests making
the system
Stefan Krah added the comment:
Scratch the comment about test_io in 2.7: It also renders the
system unusable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24831
Changes by Stefan Krah ste...@bytereef.org:
--
title: memoryviews and ctypes - memoryview: allow all casts to bytes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15944
Stefan Krah added the comment:
Ok, shall we sneak this past Larry for 3.5?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15944
___
___
Python
Stefan Krah added the comment:
If people are content with writing m[124:128] = b'abcd' and accept
that tolist() etc. won't represent the original structure of the
object, then let's do it.
On the bright side, it is less work. -- I'll review the patch
901 - 1000 of 3373 matches
Mail list logo
