[issue42050] ensurepip fails if cwd contains illformed setup.cf
New submission from Hartmut Goebel : If the current directory contains a ill-formed setup.cfg, setting up a virtual env fails, caused by ensurepip failing: Expected behaviour: running ensurepip should completely ignore the content of the current working directory. How to reproduce: $ rm -rf /tmp/v2 $ mkdir /tmp/v2 $ cd /tmp/v2 $ cat > setup.cfg < [options] > setuptools_requires > EOF $ python3 -m venv /tmp/v2/_venv Error: Command '['/tmp/v2/_venv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 2. $ /tmp/v2/_venv/bin/python3 -Im ensurepip --upgrade --default-pip Looking in links: /tmp/tmpimoh6tke Collecting setuptools Collecting pip Installing collected packages: setuptools, pip Exception: … configparser.ParsingError: Source contains parsing errors: 'setup.cfg' [line 2]: 'setuptools_requires\n' Environment: Tested with both Python 3.8.2 and 3.7.6 -- components: Library (Lib) messages: 378706 nosy: htgoebel priority: normal severity: normal status: open title: ensurepip fails if cwd contains illformed setup.cf type: crash versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue42050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38653] pkgutil.extend_path fails with zipped eggs if not at first place
New submission from Hartmut Goebel : I have a test site containing nested namespace packages in zipped and unzipped eggs_ - nspkg3_aaa.egg - unzipped egg, namespaces: nspkg3 - nspkg3_bbb.egg - zipped egg , namespaces: nspkg3, nspkg3.bbb - nspkg3_ccc.egg - unzipped egg, namespaces: nspkg3 When using order "aaa, bbb, ccc" in PYTHONPATH, importing "nspkg3.bbb" FAILS, whereas when using order "bbb, aaa, ccc" in PYTHONPATH, importing "nspkg3.bbb" PASSES, I would expect "nspk3.bbb" to ba importable 8as a namespace package) no matter which possition it has in PYTHONPATH. How to reproduce Preperation: get hands on the eggs in question: $ wget https://github.com/pyinstaller/pyinstaller/archive/v3.5.zip $ unzip v3.5.zip $ cd pyinstaller-3.5/tests/functional/modules/nspkg3-pkg/ Order "aaa, bbb, ccc": fails $ PYTHONPATH=nspkg3_aaa.egg:nspkg3_bbb.egg:nspkg3_ccc.egg python3.7 -c "import nspkg3.bbb.zzz" Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'nspkg3.bbb' Order "bbb, aaa, ccc": passes: $ PYTHONPATH=nspkg3_bbb.egg:nspkg3_aaa.egg:nspkg3_ccc.egg python3.7 -c "import nspkg3.bbb.zzz" this is module nspkg3.bbb.zzz Further information I did some research and found that the zipped egg (bbb) is *not added* to the package path when using order "aaa, bbb, ccc": Order "aaa, bbb, ccc": bbb is missing here $ PYTHONPATH=nspkg3_aaa.egg:nspkg3_bbb.egg:nspkg3_ccc.egg \ python3.7 -c "import nspkg3 ; print(nspkg3.__path__)" ['…/nspkg3_aaa.egg/nspkg3', '…/nspkg3_ccc.egg/nspkg3'] Order "bbb, aaa, ccc": bbb is included $ PYTHONPATH=nspkg3_bbb.egg:nspkg3_aaa.egg:nspkg3_ccc.egg \ python3.7 -c "import nspkg3 ; print(nspkg3.__path__)" ['…/nspkg3_bbb.egg/nspkg3', '…/nspkg3_aaa.egg/nspkg3', '…/nspkg3_ccc.egg/nspkg3'] Also tested with Python 2.7: Same results -- components: Library (Lib) messages: 355745 nosy: htgoebel priority: normal severity: normal status: open title: pkgutil.extend_path fails with zipped eggs if not at first place type: behavior versions: Python 2.7, Python 3.7 ___ Python tracker <https://bugs.python.org/issue38653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33042] New 3.7 startup sequence crashes PyInstaller
Hartmut Goebel <h.goe...@crazy-compilers.com> added the comment: I can confirm that c6d94c37f4fd863c73fbfbcc918fd23b458b5301 makes the PyInstaller test-case, which war the origin of this bug-report, pass. Thanks for fixing! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33128] PathFinder is twice on sys.meta_path
New submission from Hartmut Goebel <h.goe...@crazy-compilers.com>: As of Python 3.7.0b2 _frozen_importlib_external.PathFinder exists twice on sys.meta_path, and it is the same object: $ python -S Python 3.7.0b2 (default, Mar 22 2018, 20:09:00) [GCC 5.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print(sys.meta_path) [, , , ] >>> print([id(p) for p in sys.meta_path]) [24427944, 24430216, 24517416, 24517416] >>> -- components: Interpreter Core messages: 314340 nosy: htgoebel priority: normal severity: normal status: open title: PathFinder is twice on sys.meta_path type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33042] New 3.7 startup sequence crashes PyInstaller
New submission from Hartmut Goebel <h.goe...@crazy-compilers.com>: PyInstaller is a tool for freezing Python applications into stand-alone packages, much like py2exe. py2app, and bbfreeze. PyInstaller is providing *one* bootloader for all versions of Python supported (2.7, 3.4-3.6). In PyInstaller the startup sequence is implemented in pyi_pylib_start_python() in bootloader/src/pyi_pythonlib.c. The workflow roughly is: - SetProgramName - SetPythonHome - Py_SetPath - Setting runtime options - some flags using the global variables - PySys_AddWarnOption -> crash - Py_Initialize - PySys_SetPath The crash occurs due to tstate (thread state) not being initialized when calling PySys_AddWarnOption. -- components: Interpreter Core messages: 313546 nosy: htgoebel priority: normal severity: normal status: open title: New 3.7 startup sequence crashes PyInstaller type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31532] Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex with PyMem_Raw_Free
New submission from Hartmut Goebel:
When using
Py_GetPath();
Py_SetPath(pypath_w);
near the beginning of a program, Py_SetPath crashes with memory corruption if
run on a systems with glibc's MALLOC_CHECK enabled.
The reason is: Py_GetPath and Py_SetPath use different memory interfaces.
* Py_GetPath() calls calculate_path(), which uses PyMem_New() to allocate the
memory (see
https://github.com/python/cpython/blob/v3.6.0/Modules/getpath.c#L738, assigned
to `buf` first)
* But Py_SetPath() uses PyMem_RawFree() to free the memory (see
https://github.com/python/cpython/blob/v3.6.0/Modules/getpath.c#L830).
This error DOES NOT occur on Windows, since for win32 there is a separate
implementation, which uses PyMem_RawMalloc (see
https://github.com/python/cpython/blob/v3.6.0/PC/getpathp.c#L378).
This error also DOES NOT occur in Python <= 3.5, since PYMEM_FUNCS have been
the same as PYRAW_FUNCS (see
https://github.com/python/cpython/blob/v3.5.0/Objects/obmalloc.c#L148). This
was changed in v3.6.0: PYMEM_FUNCS now is PYOBJ_FUNCS, see
https://github.com/python/cpython/blob/v3.6.0/Objects/obmalloc.c#L159.
This error only occurs when running on a system with glibc's MALLOC_CHECK
enabled, which seems to be the default st least on CentOS, Fedora and ArchLinux.
Example code and relevant source see below.
Example stack trace
*** glibc detected *** ./dist/jcollect3: double free or corruption (out):
0x7fde271ab030 ***
=== Backtrace: =
/lib64/libc.so.6[0x37f0675e66]
/lib64/libc.so.6[0x37f06789b3]
/tmp/_MEIhKg3kx/libpython3.6m.so.1.0(Py_SetPath+0x15)[0x7fde2d20e825]
./dist/jcollect3[0x4043e2]
./dist/jcollect3[0x402db2]
./dist/jcollect3[0x402fb0]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x37f061ed5d]
./dist/jcollect3[0x401a9e]
=== Memory map:
How to reproduce
~
An example for this problem is the bootloader of PyInstaller (as of 2017-08-01).
* Make sure you are running on a Linux distribution having glibc's MALLOC_CHECK
enabled.
* Set up a virtual environment (just too keep your system clean)
pip install
https://github.com/pyinstaller/pyinstaller/archive/develop@%7B2017-08-01%7D.zip
echo 'print("Hello")' > test.py
pyinstaller test.py
dist/test/test # run the frozen script
The relevant source of PyInstaller's bootloader is at
<https://github.com/pyinstaller/pyinstaller/blob/develop@%7B2017-08-01%7D/bootloader/src/pyi_pythonlib.c#L466>
--
components: Interpreter Core
messages: 302624
nosy: htgoebel
priority: normal
severity: normal
status: open
title: Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex
with PyMem_Raw_Free
type: crash
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31532>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15373] copy.copy() does not properly copy os.environment
New submission from Hartmut Goebel h.goe...@crazy-compilers.com: Wehn copying os.environ usinf copy.copy(), any manipulation on the copied object will change os.environment, too. $ python Python 2.7.3 (default, Apr 22 2012, 07:46:58) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import copy, os os.environ['TITI'] Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/UserDict.py, line 23, in __getitem__ raise KeyError(key) KeyError: 'TITI' env = copy.copy(os.environ) env['TITI'] = 'in den Ferien' os.environ['TITI'] 'in den Ferien' Strictly speaking, this is correct, as the os.environment class is meant to manipulate the environment in the background. But user's expectation is different: he thinks, manipulating the copied object is save and does not effect the environment. -- messages: 165631 nosy: htgoebel priority: normal severity: normal status: open title: copy.copy() does not properly copy os.environment type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15373 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2946] setuptools: bdist_wininst adds duplicate entry to dist_files
Hartmut Goebel [EMAIL PROTECTED] added the comment: Yes. I've coincidently found the setptools bugtracker today and filed a bug-report there. Please Close. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2946 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2945] bdist_rpm does not list dist files (should effect upload)
New submission from Hartmut Goebel [EMAIL PROTECTED]: In Python 2.5 distutils has a bug in bdist_rpm: Generated distribution files are not listed in ``distribution.dist_files``. Thus .rpms can not be handled by other tools, eg. ``upload``. I need this bug fixed for automated upload of files using http://origo-submit.origo.ethz.ch. Enclosed please find a simple package to show the bug. Just run python setup.py bdist_rpm and watch the (missing) output. In contrast see the output of python setup.py sdist Additionally: While untested, this should effect distutils ``upload`` command. RPMs are not in the dist_files list and when looking at the source, there seams to be no 'trick' to add them later. -- components: Distutils files: simple-0.0.0.0.1.tar.gz messages: 67192 nosy: htgoebel severity: normal status: open title: bdist_rpm does not list dist files (should effect upload) versions: Python 2.5 Added file: http://bugs.python.org/file10403/simple-0.0.0.0.1.tar.gz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2945 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2945] bdist_rpm does not list dist files (should effect upload)
Changes by Hartmut Goebel [EMAIL PROTECTED]: -- type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2945 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2946] setuptools: bdist_wininst adds duplicate entry to dist_files
New submission from Hartmut Goebel [EMAIL PROTECTED]: In setuptools 0.6c8 has a bug in bdist_wininst: Distribution files are listed twice ``distribution.dist_files``. This hinders developing tools which use this data. In addition ``upload`` will upload the file twice to pypi. I need this bug fixed for automated upload of files using http://origo-submit.origo.ethz.ch;. Enclosed please find a simple package to show the bug. Just run python setup.py bdist_wininst this shows one entry. Now run python setup-setuptools.py bdist_wininst this shows two entires. The only difference between both setup files is wherefrom setup() is imported. -- components: Distutils files: simple-0.0.0.0.1.tar.gz messages: 67193 nosy: htgoebel severity: normal status: open title: setuptools: bdist_wininst adds duplicate entry to dist_files type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10404/simple-0.0.0.0.1.tar.gz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2946 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
