Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset fbdd3eeba3e526e162f2eb54d224cf36ed8cfea1 by xdegaye in branch
'2.7':
[2.7] bpo-31934: Abort when building out of a not clean source tree (GH-4255).
(#4342)
https://github.com/python/cpython/
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Oh I understand, there is no practical way to test that feature except manually.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Xavier de Gaye <xdeg...@gmail.com> added the comment:
I also tested the 2.7 and 3.6 PRs before submitting them.
Thanks for testing and for your reviews Victor :-)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset 0c4785bf39b4e86dea3a70b651e5d5db2f2cf017 by xdegaye in branch
'3.6':
[3.6] bpo-31934: Abort when building out of a not clean source tree (GH-4255).
(#4340)
https://github.com/python/cpython/
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +4298
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31934>
___
_
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +4294
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31934>
___
_
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset 0de92859caf25e65fc968d4bb68626e9ba21b851 by xdegaye in branch
'master':
bpo-31934: Abort when building out of a not clean source tree (GH-4255)
https://github.com/python/cpython/commit/0de92859caf25e65fc968d4bb68626e9ba
Xavier de Gaye <xdeg...@gmail.com> added the comment:
PR 4334 added: fix the implementation of PEP 538 on Android.
The current implementation of PEP 538 fixes issue 28997 without the locale
coercion for Android added by PR 4334, see msg
Xavier de Gaye <xdeg...@gmail.com> added the comment:
PEP 538 is implemented now in the master branch.
Closing this issue as out of date for the following reasons:
a) PR 4334 adds locale coercion for Android to the implementation of PEP 538
(and test_nonascii succeeds with this P
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +4289
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Xavier de Gaye <xdeg...@gmail.com> added the comment:
To build out of the 'src' source tree (a subdirectory of the current directory)
in a 'build' subdirectory:
$ ls -ld src
drwxr-xr-x 21 xavier xavier 4.0K Nov 3 23:50 src/
$ mkdir build
$ cd build
$ $(cd ../src && pwd)/con
Xavier de Gaye <xdeg...@gmail.com> added the comment:
When you build out of the source tree and this source tree has been built
previously (by running 'make' in the source tree), then you get the error msg
printed in msg305486 when you try to build *out* of this not clean sourc
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
keywords: +patch
pull_requests: +4217
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Xavier de Gaye <xdeg...@gmail.com>:
The error message when building out of a not clean source tree:
renaming build/scripts-3.7/2to3 to build/scripts-3.7/2to3-3.7
renaming build/scripts-3.7/pyvenv to build/scripts-3.7/pyvenv-3.7
gcc -pthread -Xlinker -export-dyna
Xavier de Gaye <xdeg...@gmail.com> added the comment:
The problem is that the build system , Py_GetPath() and the distutils module do
not handle correctly the case where the configure prefix is '/'.
Closing as a duplicate of issue 31114.
--
resolution: -> duplicate
stage: te
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Actually, sys.prefix is '/usr' because '/usr/bin' is in PATH while '/bin' is
not in PATH. After adding '/bin' to the start of PATH, then sys.prefix becomes
'/.' when Python is run as 'python3'. The confusion comes from the '/bin'
s
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Clarification about the test results:
On archlinux /bin is a symlink to /usr/bin, so on archlinux the value of
sys.prefix is '/usr' instead of the expected '/'. This is because in
Modules/getpath.c, 'argv0_path' is the directory of th
Xavier de Gaye <xdeg...@gmail.com> added the comment:
To test PR 4172 on linux one needs a chroot. The following test is run on
archlinux using systemd-nspawn (a chroot on steroids, see
https://wiki.archlinux.org/index.php/Systemd-nspawn).
1) Setup systemd-nspawn by installing arch-i
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
keywords: +patch
pull_requests: +4141
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
components: +Cross-Build -Build
nosy: +Alex.Willmer
stage: -> needs patch
title: 'make install' fails when exec_prefix is '/' and DESTDIR not empty ->
'make install' fails when the configure 'prefix' is '/' and DESTDIR is u
Xavier de Gaye <xdeg...@gmail.com> added the comment:
The infinite loop may occur if one of the functions called by
PyRun_InteractiveOneObject() returns persistently -1. This may be the case when
there is no more memory and is handled by issue 30696.
It is not possible anymore to rep
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
versions: -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30696>
___
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +4129
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
nosy: +xdegaye
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31626>
___
__
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Fixed by issue 30697.
--
resolution: -> out of date
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.5
___
Python tracker <rep...@bugs.
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset 4b27d51222be751125e6800453a39360a2dec11d by xdegaye in branch
'3.6':
[3.6] bpo-30697: Fix PyErr_NormalizeException() when no memory (GH-2327).
(#4135)
https://github.com/python/cpython/
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
keywords: +patch
pull_requests: +4098
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset 56d1f5ca32892c7643eb8cee49c40c1644f1abfe by xdegaye in branch
'master':
bpo-30697: Fix PyErr_NormalizeException() when no memory (GH-2327)
https://github.com/python/cpython/commit/56d1f5ca32892c7643eb8cee49c40c1644
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Checking the test_exceptions test cases that are added by PR 2327 on the
current master branch, before the merge of PR 2327:
* test_recursion_normalizing_exception still fails (SIGABRT on a debug build
and SIGSEGV oth
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Android has both memalign() [1] and posix_memalign() [2] and does not have
aligned_alloc(), posix_memalign() is a wrapper around memalign() [3].
[1]
https://android.googlesource.com/platform/bionic/+/master/libc/include/malloc.h
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset d5d79545b73110b2f4c2b66d150409514e2ca8e0 by xdegaye in branch
'3.6':
[3.6] bpo-30817: Fix PyErr_PrintEx() when no memory (GH-2526). (#4107)
https://github.com/python/cpython/commit/d5d79545b73110b2f4c2b66d150409514e
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +4077
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30817>
___
_
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset 66caacf2f0d6213b049a3097556e28e30440b900 by xdegaye in branch
'master':
bpo-30817: Fix PyErr_PrintEx() when no memory (#2526)
https://github.com/python/cpython/commit/66caacf2f0d6213b049a3097556e28e304
New submission from Xavier de Gaye <xdeg...@gmail.com>:
When built with: Android clang version 3.8.275480 (based on LLVM 3.8.275480)
The following warning is emitted:
ccache
/pathto/android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-target x86_64-none-linux-andro
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Removing 2.7 as the problem cannot be reproduced here.
PyEval_CallObjectWithKeywords() does not assert on PyErr_Occurred().
--
versions: -Python 2.7
___
Python tracker <rep...@bugs.p
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
stage: -> patch review
versions: -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Xavier de Gaye <xdeg...@gmail.com> added the comment:
New changeset aaf6a3dbbdb9754f98d480b468adfcae0f66e3a2 by xdegaye (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-30695: Add set_nomemory(start, stop) to _testcapi (GH-2406) (#4083)
https://github.com/python/cpython/
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Test cases in issues #30697 and #30817, back ported to 3.6, need
_testcapi.set_nomemory().
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Nick, in msg304388 you wrote "[allow] immediate write-through from trace
functions". The latest iteration of PEP 558 says instead:
"tracing mode: the way the interpreter behaves when a trace hook has been
register
Xavier de Gaye <xdeg...@gmail.com> added the comment:
> Ah, the discussion restarted on the other issue:
> http://bugs.python.org/issue20210#msg287516
Issue 20210 has ended up as a change in the build system eventually and not the
installation process, only a tiny
Change by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: -2537
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20210>
___
Xavier de Gaye <xdeg...@gmail.com> added the comment:
Philip, 9791c5d55f52 was commited in november 2013 and issue19901 was closed in
december 2013, so how can they be an appropriate solution for a problem
reported on 2017-01-13 in msg
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
nosy: +xdegaye
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31158>
___
__
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
nosy: +xdegaye
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31121>
___
__
Xavier de Gaye added the comment:
Issue 31114 is the same issue and proposes a workaround and another fix.
--
nosy: +xdegaye
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Xavier de Gaye added the comment:
In the subprocess test named test_executable_without_cwd and when the test is
run on the installed Python, argv[0] is not the python executable and
calculate_path() in Modules/getpath.c, as a last resort, searches the
directories pointed
New submission from Xavier de Gaye:
The error messages:
running install_lib
creating /lib/python3.7
error: could not create '/lib/python3.7': Permission denied
make[1]: *** [Makefile:1449: sharedinstall] Error 1
The command that triggers this failure:
_PYTHON_PROJECT_BASE
New submission from Xavier de Gaye:
When cross-compiling, the local Python interpreter that is used to run
ensurepip may not have the same value of sys.prefix as the value of the
'prefix' variable that is set in the Makefile.
With the following values used to install Python locally
Xavier de Gaye added the comment:
issue 17288 is related.
--
nosy: +xdegaye
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30953>
___
__
Xavier de Gaye added the comment:
There are just 6 cases left where the return code of _PySys_SetObjectId() is
ignored:
Python/pylifecycle.c|689 col 5| _PySys_SetObjectId(_stderr, pstderr);
Python/pylifecycle.c|1211 col 9| _PySys_SetObjectId(_stderr, pstderr);
Python/pylifecycle.c|1657 col 5
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2591
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30817>
___
_
Xavier de Gaye added the comment:
New changeset 85f643023fed3d4e2fb8e399f9ad57f3a65ef237 by xdegaye in branch
'master':
bpo-30695: Add set_nomemory(start, stop) to _testcapi (GH-2406)
https://github.com/python/cpython/commit/85f643023fed3d4e2fb8e399f9ad57f3a65ef237
Xavier de Gaye added the comment:
In msg296758 Nathaniel wrote:
> It turns out if you simply delete the LocalsToFast and FastToLocals calls in
> call_trampoline, then the test suite still passes. I'm pretty sure that pdb
> relies on this as a way to set local variables, though, s
Xavier de Gaye added the comment:
With pyerr_printex.patch we get the following correct results (rc=120 is set by
Py_Main() after Py_FinalizeEx() returns with an error):
$ ./python memerr.py 5 12
set_nomemory(0, 5)
result = _PythonRunResult(rc=1, out=b'', err=b'MemoryError\n\nDuring handling
Xavier de Gaye added the comment:
> Oh, I'm curious about that one :-)
This is issue 30817.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
New submission from Xavier de Gaye:
To reproduce the abort (the set_nomemory() function is being added to _testcapi
in issue 30695):
$ ./python memerr.py
python: Objects/call.c:89: _PyObject_FastCallDict: Assertion
`!PyErr_Occurred()' failed.
Aborted (core dumped)
The corresponding backtrace
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2537
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20210>
___
_
Xavier de Gaye added the comment:
See the related issue 5654.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30429>
___
___
Pyth
Xavier de Gaye added the comment:
Thanks for this PR Louie, adding count to the pdb commands is useful.
With gdb a very common use case is to set a breakpoint where the code runs very
frequently and when only interested in the N(th) execution of this code, to
enter the breakpoint command list
Xavier de Gaye added the comment:
> But is it useful to test N memory allocation failures in a row?
I think it is useful. See my previous post.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Xavier de Gaye added the comment:
For the record, while working on the test case of PR 2406, I found by chance
that the following script:
# Script start.
import _testcapi
class C(): pass
_testcapi.set_nomemory(0, 5)
C()
# Script end.
fails with:
python: Objects/call.c:89
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2454
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30695>
___
_
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: -2416
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30696>
___
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: -2415
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30695>
___
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2416
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30696>
___
_
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2415
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30695>
___
_
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: -2406
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30695>
___
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: -2407
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30696>
___
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2407
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30696>
___
_
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2406
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30695>
___
_
Xavier de Gaye added the comment:
PR 2327 lacks the test cases mentionned below for the moment.
1) With PR 2327, the memerr.py script runs correctly:
$ ./python /path/to/memerr.py
Fatal Python error: Cannot recover from MemoryErrors while normalizing
exceptions.
Current thread
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2376
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30697>
___
_
Xavier de Gaye added the comment:
The two issues you are refering to are the instruments that are needed to
reproduce the problem. The reference to PR 2035 is only made here to argue
about the question of the correct way to control the successive calls to
PyErr_NormalizeException
Xavier de Gaye added the comment:
Good point. Not freeing the memory made the implementation of
set_nomemory_allocator() simpler, no need to call PyMem_GetAllocator(). Forget
about this point, sorry :-)
--
___
Python tracker <rep...@bugs.python.
Xavier de Gaye added the comment:
I am not sure, failmalloc.enable(range) accepts only range > 1, hook_malloc()
fails only once instead of permanently and hook_free() does free memory.
--
___
Python tracker <rep...@bugs.python.org&
Xavier de Gaye added the comment:
The chain of events following a call to set_nomemory_allocator() is
deterministic, this is another difference with pyfailmalloc. Also what happens
then after this call is not very close to real life as memory is never freed.
Having the possibility to trigger
Xavier de Gaye added the comment:
The patch is far too simplistic. With this patch an exception kills the
interactive loop, for example:
$ ./python -q
>>> x
Traceback (most recent call last):
File "", line 1, in
NameError: name
Xavier de Gaye added the comment:
> I think the allocators must just return NULL, without setting the error.
You are right, thanks.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Xavier de Gaye added the comment:
Yes, actually I thought first about re-opening issue 19817 instead of opening
this new issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Xavier de Gaye added the comment:
Problem b) is IMO a clear demonstration that using tstate->recursion_depth and
the PyExc_RecursionErrorInst singleton is not the correct way to control the
recursive calls to PyErr_NormalizeException() since the problem here is memory
exhaust
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
versions: +Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
versions: +Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Xavier de Gaye:
Nosying reviewers of PR 1981 of issue 22898.
The memerr.py script segfaults with the following gdb backtrace:
#0 0x00550268 in PyErr_NormalizeException
(exc=exc@entry=0x7fffdee8,
val=val@entry=0x7fffdef0, tb=tb@entry=0x7fffdef8
New submission from Xavier de Gaye:
To reproduce the problem, apply the nomemory_allocator.patch from issue 30695
and run the following two statements that must be interrupted with ^C:
$ ./python -q
>>> import _testcapi
>>> _testcapi.set_nomemory_allocator()
sys.excepthook i
New submission from Xavier de Gaye:
Add the set_nomemory_allocator() function to _testcapi that sets a no memory
allocator.
--
components: Tests
files: nomemory_allocator.patch
keywords: patch
messages: 296266
nosy: haypo, xdegaye
priority: normal
severity: normal
status: open
title
Xavier de Gaye added the comment:
> We can't just remove PyExc_RecursionErrorInst since this can cause a stack
> overflow
Please give an example where a stack overflow occurs when
PyExc_RecursionErrorInst has been removed.
--
___
Python t
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
nosy: +brett.cannon
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22898>
___
_
Xavier de Gaye added the comment:
Antoine asked in PR 1981:
> Did you verify the removed code here wasn't needed anymore?
Just checked that crasher infinite_rec_2.py (removed by 1e534b5) does not crash
with PR 1981. The other crashers listed at 1e534b5 are not valid Python 3.7
code. D
Xavier de Gaye added the comment:
With PR 1981, a ResourceWarning is printed when a RecursionError occurs while
normalizing another exception and its traceback holds a reference to a
non-closed file object.
For information, issue 5437 removed the MemoryError singleton for the same
reasons
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
pull_requests: +2049
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22898>
___
_
Xavier de Gaye added the comment:
I don't intend to change the current code in PR 1629 until there is a review or
comments asking for changes. Ned Deily has self-requested a review, reviews
from other people are also welcome.
--
___
Python tracker
Xavier de Gaye added the comment:
Details of commit "Update the native interpreter build on Setup.dist and
version changes." in 408c05d44c6310b4a2f0659333560eca6071c8a5:
Native interpreter build:
* Copy Setup.dist to Setup when Setup.dist has been changed.
* Run 'make distclean' upo
Xavier de Gaye added the comment:
Details of commit "Add Makefile targets to implement the buildbot steps" in
543a287c32a714a668e426ceb80f4add92cc5de4:
The following buildbot steps, as defined by the UnixBuild class of the
master.cfg buildbot configuration file, have now their cor
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
title: Provide configure options to enable/disable Python modules and
extensions -> Support the *disabled* mar
Xavier de Gaye added the comment:
New changeset c0364fc7c2693fb070917ee62aeb8d2551710821 by xdegaye in branch
'master':
bpo-20210: Support the *disabled* marker in Setup files (GH-132)
https://github.com/python/cpython/commit/c0364fc7c2693fb070917ee62aeb8d2551710821
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Xavier de Gaye added the comment:
New changeset 50e86033de85294d87b7e942701d456342abde8e by xdegaye in branch
'master':
bpo-29619: Do not use HAVE_LARGEFILE_SUPPORT for type conversions (GH-1666).
https://github.com/python/cpython/commit/50e86033de85294d87b7e942701d456342abde8e
401 - 500 of 1480 matches
Mail list logo
