Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28125>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue22724>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue26971>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue26859>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
resolution: -> works for me
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue31114>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
As a workaround insert the following hard-coded breakpoint before the import
statement and run your script with python, i.e. 'python myhome.py' instead of
'python -m pdb myhome.p'.
from pdb import Pdb; Pdb(skip=['importlib*']
Xavier de Gaye added the comment:
PYTHON_FOR_BUILD does not use PYTHONPATH in the implementation of (closed) PR
17420 and should fix the current issue as a side effect.
FWIW, PR 17420 fixes cross-compilation of third-party extension modules by
replacing the complex PYTHON_FOR_BUILD command
Xavier de Gaye added the comment:
In msg360620 Serhiy wrote:
> When the interpreter encounters "import foo" in bar.py, the import machinery
> takes the module foo from sys.modules.
> So you break an infinite cycle and can import modules with cyclic
> dependencies.
The
Xavier de Gaye added the comment:
This fixed the bug.
To reproduce the bug, substitute the "from _lzma import *" statement with
"raise ImportError"
in Lib/lzma.py to simulate that the _lzma module is missing and run the test.py
script written an
Xavier de Gaye added the comment:
Steve wrote:
> In my build, I've set PYTHON_FOR_BUILD=python3.8
This will not work, PYTHON_FOR_BUILD when cross-compiling is set by configure
as:
PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir)
_PYTHON_HOST_PLATFORM=$(_PYTHON_
Xavier de Gaye added the comment:
> Is that epic line automatically generated?
When cross compiling it is generated by the configure script and configure
replaces the right hand side of "PYTHON_FOR_BUILD=@PYTHON_FOR_BUILD@" of
Makefile.pre.in with the generated value into Mak
Xavier de Gaye added the comment:
In Kerrick's example ast.literal_eval('') could be ast.literal_eval(some_code)
instead where some_code is a string containing dynamically generated Python
code. pdb post-mortem debugging must allow finding the syntax error in this
code. The
Xavier de Gaye added the comment:
> Perhaps we should should test whether the exception happened there and not
> drop in the debugger in that case?
The same kind of problem occurs for any post-mortem debugging raised by an
uncaught exception in the user code: the backtrace displayed
Xavier de Gaye added the comment:
This message is just a reminder that this 4 months old issue raises
the point that the step command in pdb is broken. A patch and test
case have been proposed.
No comment so far.
As the author of pyclewn, a Vim front end to pdb and gdb, I would be
grateful for
Xavier de Gaye added the comment:
What do you mean ?
What is "this" ?
--
___
Python tracker
<https://bugs.python.org/issue28971>
___
___
Python-bugs-l
Xavier de Gaye added the comment:
FWIW I checked the Android build after those last changes.
--
___
Python tracker
<https://bugs.python.org/issue21536>
___
___
Xavier de Gaye added the comment:
@gphemsley
Can you please provide the output of running test_xml_etree with tracing.
--
nosy: +xdegaye
___
Python tracker
<https://bugs.python.org/issue36
Xavier de Gaye added the comment:
> While typically pdb is not used in tests, it is just good practice, given
> that there can only be a single trace function.
IMO invoking "good practice" is not sufficient to motivate such a change.
The proposed change is not backward comp
Xavier de Gaye added the comment:
> Would it work to store it on the class then (once)?
A motivation for this change should be provided first: the incorrect behavior
it is trying to fix or the enhancement it is providing.
--
___
Python trac
Xavier de Gaye added the comment:
> Is getting accurate coverage reports not enough?
But it does not achieve that goal, does it ?
--
___
Python tracker
<https://bugs.python.org/issu
Xavier de Gaye added the comment:
The main goal of test coverage is to verify that the tests cover the code that
is being tested, it is not to get '100 %' printed. Measuring the coverage of
the tests themselves is entirely another matter and not very useful. Since it
is not p
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.
--
___
Pyt
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
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:
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) at
Changes by Xavier de Gaye :
--
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue30696>
___
___
Python-bugs-list mailing list
Unsub
Changes by Xavier de Gaye :
--
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue30697>
___
___
Python-bugs-list mailing list
Unsub
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
exhaustion,
Xavier de Gaye added the comment:
Yes, actually I thought first about re-opening issue 19817 instead of opening
this new issue.
--
___
Python tracker
<http://bugs.python.org/issue30
Xavier de Gaye added the comment:
> I think the allocators must just return NULL, without setting the error.
You are right, thanks.
--
___
Python tracker
<http://bugs.python.org/issu
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:
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:
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
<http://bugs.python.org/issu
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
<h
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(). This
Changes by Xavier de Gaye :
--
pull_requests: +2376
___
Python tracker
<http://bugs.python.org/issue30697>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
pull_requests: +2406
___
Python tracker
<http://bugs.python.org/issue30695>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: +2407
___
Python tracker
<http://bugs.python.org/issue30696>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: -2407
___
Python tracker
<http://bugs.python.org/issue30696>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: -2406
___
Python tracker
<http://bugs.python.org/issue30695>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: +2415
___
Python tracker
<http://bugs.python.org/issue30695>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: +2416
___
Python tracker
<http://bugs.python.org/issue30696>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: -2415
___
Python tracker
<http://bugs.python.org/issue30695>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: -2416
___
Python tracker
<http://bugs.python.org/issue30696>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
pull_requests: +2454
___
Python tracker
<http://bugs.python.org/issue30695>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<http://bugs.python.org/issu
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:
See the related issue 5654.
--
___
Python tracker
<http://bugs.python.org/issue30429>
___
___
Python-bugs-list mailing list
Unsub
Changes by Xavier de Gaye :
--
pull_requests: +2537
___
Python tracker
<http://bugs.python.org/issue20210>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 back
Xavier de Gaye added the comment:
> Oh, I'm curious about that one :-)
This is issue 30817.
--
___
Python tracker
<http://bugs.python.org/issue30695>
___
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\n
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:
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/85f643023fed3d4e2fb8e399f9ad57
Changes by Xavier de Gaye :
--
pull_requests: +2591
___
Python tracker
<http://bugs.python.org/issue30817>
___
___
Python-bugs-list mailing list
Unsubscribe:
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(&PyId_stderr, pstderr);
Python/pylifecycle.c|1211 col 9| _PySys_SetObjectId(&PyId_stderr, pstderr);
Python/pylif
Xavier de Gaye added the comment:
issue 17288 is related.
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue30953>
___
___
Python-bugs-list mailin
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 loc
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_PR
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 to by the
Xavier de Gaye added the comment:
Issue 31114 is the same issue and proposes a workaround and another fix.
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue9
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue31121>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue31158>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Xavier de Gaye :
The call to subprocess.Popen() in collect_cc() of Lib/test/pythoninfo.py raises
an exception when the compiler that has been used to build python is not
present on the host running python. In that case pythoninfo prints a stack
trace and exits with an
Xavier de Gaye added the comment:
This problem has been fixed in python 3.7.
Most of the changes made to fix the problems of cross-building python for
android have been done on python 3.7.
--
___
Python tracker
<https://bugs.python.
Xavier de Gaye added the comment:
It is not yet possible to cross-compile python extensions. The reason is that
_init_posix() in Lib/sysconfig.py still reads the sysconfigdata module of the
native compiler instead of the sysconfigdata of the cross-built one. See the
patch in issue #28833
Xavier de Gaye added the comment:
The compilation of Modules/posixmodule.c fails now on Android architecture
'x86' at api level 21, after the above change
0f6d73343d342c106cda2219ebb8a6f0c4bd9b3c:
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
--sysroot=/opt/a
Xavier de Gaye added the comment:
sizeof(unsigned long long) is 8 on Android x86 and HAVE_LARGEFILE_SUPPORT is
undefined.
According to msg280053 HAVE_LARGEFILE_SUPPORT is also undefined on Android
x86_64 (and also on Linux x86_64).
> Maybe the code should be simplified to always use unsig
Xavier de Gaye added the comment:
> The file is nearly devoid of docstrings, so I would like to add those first,
> probably in a separate patch.
Please move this new request for enhancement to a separate issue.
--
___
Python tracker
Xavier de Gaye added the comment:
Thanks Terry and Cheryl for splitting the issue :)
--
___
Python tracker
<http://bugs.python.org/issue19417>
___
___
Python-bug
New submission from Xavier de Gaye:
This PR adds a build infrastructure for Android on linux that allows a
developer to check that source code changes do not break the existing state of
this support by testing the changes on Android with a simple command. For
example after a change to the
Changes by Xavier de Gaye :
--
pull_requests: +1720
___
Python tracker
<http://bugs.python.org/issue30386>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
The build system for the x86_64, x86 and armv7 architectures has been tested on
API 21 and for the x86_64 and arm64 architectures on API 24. Of these
combinations of architecture/api, only x86_64 on API 21 builds correctly today,
the others were building
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file46871/android-api-24.patch
___
Python tracker
<http://bugs.python.org/issue30386>
___
___
Python-bug
Xavier de Gaye added the comment:
In configure.ac, HAVE_LARGEFILE_SUPPORT is defined if (off_t > long && longlong
>= off_t) and thus, when it is not defined, it means that off_t <= long (since
longlong < off_t is false) so an off_t should fit into a long. But on Android
Xavier de Gaye added the comment:
> What is the type of st_ino? It's not off_t?
The type of st_ino is unsigned long long as defined in sys/stat.h for x86 and
off_t is defined in sys/types.h this way;, quoting:
/* This historical accident means that we had a 32-bit off_t o
Xavier de Gaye added the comment:
With the patch proposed by Victor in msg293873 the cross-compilation of
posixmodule.c succeeds on android-21-x86 and android-21-x86_64.
Following my suggestion in msg292174, I propose the following patch instead:
diff --git a/Modules/posixmodule.c b/Modules
Xavier de Gaye added the comment:
> The same kind of fix could also be applied elsewhere in posixmodule.c
By also adding a Py_BUILD_ASSERT() statement which is a welcome improvement on
the previous code that allowed to pinpoint the problem on Andr
Xavier de Gaye added the comment:
Commited 'bpo-30386: Support the new NDK Unified Headers'.
This does fix the missing declarations in the NDK headers and
android-api-24.patch is not needed now.
It also fixes the missing declaration of sethostname() at API 24 that caused
the imp
Changes by Xavier de Gaye :
--
pull_requests: +1761
___
Python tracker
<http://bugs.python.org/issue29619>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
PR 1666 added.
With Unified Headers introduced in android-ndk-r14, the size of off_t for 32
bits Android devices is 8 instead of 4 and the cross-compilation of Python on
Android does not fail in this case, see msg293956
Xavier de Gaye added the comment:
Good point.
PyLong_FromLong() is faster than PyLong_FromLongLong(), IMO the fastest should
be used when it is possible.
PyLong_FromUnsignedLong() and PyLong_FromUnsignedLongLong() are almost
identical, they implement the same algorithm. The first one uses
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/50e86033de85294d87b7e942701d45
Changes by Xavier de Gaye :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29619>
___
___
Python-bugs-list
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/c0364fc7c2693fb070917ee62aeb8d
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
title: Provide configure options to enable/disable Python modules and
extensions -> Support the *disabled* marker in Setup files
___
Py
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
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
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 tr
Changes by Xavier de Gaye :
--
pull_requests: +2049
___
Python tracker
<http://bugs.python.org/issue22898>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 as
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
cod
Changes by Xavier de Gaye :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue22898>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
What is the NDK version ?
There is no Android pthread library. It is possible that the failure comes from
the fact that the first configure test on pthread_create links with pthread and
that the Android linker fails now instead of ignoring this error as it
Xavier de Gaye added the comment:
> The problem extends after the configuration. It's as if the android headers
> are not visible to configure. All the macros are undefined in the pyconfig
> file too btw.
pyconfig.h is generated by configure from pyconfig.h.in.
Please attach
Xavier de Gaye added the comment:
This is a different problem. Please create a new issue and attach pyconfig.h.
--
___
Python tracker
<https://bugs.python.org/issue36
101 - 200 of 1492 matches
Mail list logo
