[issue43710] Access violations in C extension modules on Python 3.9.3
Christoph Gohlke added the comment: Thank you for fixing this issue so fast! Python 3.9.4 works well. -- ___ Python tracker <https://bugs.python.org/issue43710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43710] Access violations in C extension modules on Python 3.9.3
New submission from Christoph Gohlke : First reported at https://github.com/numpy/numpy/issues/18720 After upgrading to Python 3.9.3, 32-bit on Windows, importing numpy (installed via `pip install numpy`) crashes: ``` Microsoft Windows [Version 10.0.19041.906] C:\Python39-32>python -X dev Python 3.9.3 (tags/v3.9.3:e723086, Apr 2 2021, 11:01:03) [MSC v.1928 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy Windows fatal exception: access violation Current thread 0x105c (most recent call first): File "", line 228 in _call_with_frames_removed File "", line 1116 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 228 in _call_with_frames_removed File "", line 1116 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 228 in _call_with_frames_removed File "", line 1116 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "C:\Python39-32\lib\site-packages\numpy\random\_pickle.py", line 1 in File "", line 228 in _call_with_frames_removed File "", line 790 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 228 in _call_with_frames_removed File "", line 1058 in _handle_fromlist File "C:\Python39-32\lib\site-packages\numpy\random\__init__.py", line 179 in File "", line 228 in _call_with_frames_removed File "", line 790 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 228 in _call_with_frames_removed File "", line 1058 in _handle_fromlist File "C:\Python39-32\lib\site-packages\numpy\__init__.py", line 156 in File "", line 228 in _call_with_frames_removed File "", line 790 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 1 in ``` Rebuilding numpy from source against Python 3.9.3 fixes this crash, but many other packages compiled against older versions of Python 3.9.x still crash. I think this might be due to <https://github.com/python/cpython/commit/8b795ab5541d8a4e69be4137dfdc207714270b77#diff-7285576bdacf86fe37274d3d0d399c29b4be2959005f60ac0729615d8fca9186>. In `bpo-42500: Fix recursion in or after except (GH-23568) (#24501)`, the public `PyThreadState` struct changed. This breaks ABI compatibility for code that is directly accessing the `PyThreadState` struct members, which is not uncommon. E.g. in Cython <https://github.com/cython/cython/blob/0.29.x/Cython/Utility/Exceptions.c#L93-L115>. This code will fail on 32-bit. On 64-bit it passes because of fortunate struct alignment AFAICT. -- components: Extension Modules, Windows messages: 390116 nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Access violations in C extension modules on Python 3.9.3 type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41237] Access violation in python39.dll!meth_dealloc on exit
Christoph Gohlke added the comment: This issue seems specific to C extensions built with pybind11 (using 2.5.0 and master branch). Building the minimal example at https://github.com/pybind/python_example and running `python.exe -c"import python_example"` will crash at exit. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue41237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41237] Access violation in python39.dll!meth_dealloc on exit
Change by Christoph Gohlke : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue41237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41237] Access violation in python39.dll!meth_dealloc on exit
Christoph Gohlke added the comment: I tracked this to an import of the numba-0.50.1 package during the numpy tests. `python -c"import numba'` is enough to reproduce this crash during interpreter exit. Probably the package needs to be ported to Python 3.9. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41237] Access violation in python39.dll!meth_dealloc on exit
Change by Christoph Gohlke : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue41237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41237] Access violation in python39.dll!meth_dealloc on exit
New submission from Christoph Gohlke :
When testing extension packages on Python 3.9.0b4 for Windows, I often get
access violations in `python39.dll!meth_dealloc` during interpreter exit. The
crash only happens when heap verification is turned on (`"C:\Program Files
(x86)\Windows Kits\10\Debuggers\x86\gflags.exe" /p /enable python.exe`;
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags). The
debug build does not crash.
Could be related to "PEP 573: Module State Access from C Extension Methods",
https://bugs.python.org/issue38787
To reproduce the crash with with numpy-1.19.0 (built from source):
```
Python 3.9.0b4 (tags/v3.9.0b4:69dec9c, Jul 2 2020, 21:46:36) [MSC v.1924 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy;numpy.test()
NumPy version 1.19.0
10364 passed, 438 skipped, 108 deselected, 17 xfailed, 1 xpassed in 243.52s
(0:04:03)
True
>>> exit()
Windows fatal exception: access violation
Current thread 0x2688 (most recent call first):
```
The crash is at
<https://github.com/python/cpython/blob/1d1c5743400bdf384ec83eb6ba5b39a355d121e3/Objects/methodobject.c#L169>:
```
static void
meth_dealloc(PyCFunctionObject *m)
{
_PyObject_GC_UNTRACK(m);
if (m->m_weakreflist != NULL) {
PyObject_ClearWeakRefs((PyObject*) m);
}
Py_XDECREF(m->m_self);
Py_XDECREF(m->m_module);
Py_XDECREF(PyCFunction_GET_CLASS(m)); /* <-- crash */
PyObject_GC_Del(m);
}
```
Call Stack:
```
> python39.dll!meth_dealloc(PyCFunctionObject * m) Line 169 C
[Inline Frame] python39.dll!_Py_Dealloc(_object *) Line 2209C
[Inline Frame] python39.dll!_Py_DECREF(_object *) Line 430 C
[Inline Frame] python39.dll!_Py_XDECREF(_object * op) Line 497 C
[Inline Frame] python39.dll!free_keys_object(_dictkeysobject *) Line
598C
[Inline Frame] python39.dll!dictkeys_decref(_dictkeysobject *) Line 333
C
python39.dll!dict_dealloc(PyDictObject * mp) Line 2026 C
[Inline Frame] python39.dll!_Py_Dealloc(_object *) Line 2209C
[Inline Frame] python39.dll!_Py_DECREF(_object *) Line 430 C
python39.dll!_PyInterpreterState_ClearModules(_is * interp) Line 768
C
python39.dll!_PyImport_Cleanup(_ts * tstate) Line 628 C
python39.dll!Py_FinalizeEx() Line 1432 C
python39.dll!Py_Exit(int sts) Line 2433 C
python39.dll!handle_system_exit() Line 696 C
python39.dll!_PyErr_PrintEx(_ts * tstate, int set_sys_last_vars) Line
708 C
[Inline Frame] python39.dll!PyErr_Print() Line 807 C
python39.dll!PyRun_InteractiveLoopFlags(_iobuf * fp, const char *
filename_str, PyCompilerFlags * flags) Line 137 C
python39.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char * filename,
int closeit, PyCompilerFlags * flags) Line 81 C
python39.dll!pymain_run_stdin(PyConfig * config, PyCompilerFlags * cf)
Line 509 C
python39.dll!pymain_run_python(int * exitcode) Line 597 C
python39.dll!Py_RunMain() Line 675 C
python39.dll!Py_Main(int argc, wchar_t * * argv) Line 716 C
[External Code]
```
Locals:
```
- m 0x01fbea75ddb0 {ob_base={ob_refcnt=0
ob_type=0x7fff5a1e5650 {python39.dll!_typeobject PyCFunction_Type} {...} }
...}PyCFunctionObject *
- ob_base {ob_refcnt=0 ob_type=0x7fff5a1e5650
{python39.dll!_typeobject PyCFunction_Type} {ob_base={ob_base=...} ...} }
_object
ob_refcnt 0 __int64
- ob_type 0x7fff5a1e5650 {python39.dll!_typeobject
PyCFunction_Type} {ob_base={ob_base={ob_refcnt=23 ob_type=...} ...} ...}
_typeobject *
+ ob_base {ob_base={ob_refcnt=23 ob_type=0x7fff5a1e7c60
{python39.dll!_typeobject PyType_Type} {ob_base={ob_base=...} ...} } ...}
PyVarObject
+ tp_name 0x7fff5a16d8a0 "builtin_function_or_method" const
char *
tp_basicsize56 __int64
tp_itemsize 0 __int64
tp_dealloc 0x7fff59e2c260
{python39.dll!meth_dealloc(PyCFunctionObject *)} void(*)(_object *)
tp_vectorcall_offset48 __int64
tp_getattr 0x _object *(*)(_object *,
char *)
tp_setattr 0x int(*)(_object *, char
*, _object *)
+ tp_as_async 0xPyAsyncMethods *
tp_repr 0x7fff59e5c430
{python39.dll!meth_repr(PyCFunctionObject *)}_object *(*)(_object *)
+ tp_as_number0xPyNumberMethods
*
+ tp_as_sequence 0x
PySequenceMethods *
+ tp_as_mapp
[issue37993] os.path.realpath on Windows resolves mapped network drives
New submission from Christoph Gohlke :
Re https://bugs.python.org/issue9949:
Is it intended that Python-3.8.0b4 now also resolves mapped network drives and
drives created with `subst`?
I would not expect this from the documentation at
https://docs.python.org/3.8/library/os.path.html#os.path.realpath. The
documentation refers to symbolic links and junctions, which are different from
mapped network and subst drives (AFAIU).
For example, mapping `\\SERVER\Programs` as `X:` drive:
```
Python 3.8.0b4 (tags/v3.8.0b4:d93605d, Aug 29 2019, 23:21:28) [MSC v.1916 64
bit (AMD64)] on win32
>>> import sys, os
>>> sys.executable
'X:\\Python38\\python.exe'
>>> os.path.realpath(sys.executable)
'SERVER\\Programs\\Python38\\python.exe'
```
```
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit
(AMD64)] on win32
>>> import sys, os
>>> sys.executable
'X:\\Python37\\python.exe'
>>> os.path.realpath(sys.executable)
'X:\\Python37\\python.exe'
```
It seems this change causes an error in pytest-5.1.2 during numpy-1.17.1 tests:
```
X:\Python38>python.exe -c"import numpy;numpy.test()"
NumPy version 1.17.1
NumPy relaxed strides checking option: True
= ERRORS
==
__ ERROR collecting test session
__
lib\site-packages\_pytest\config\__init__.py:440: in _importconftest
return self._conftestpath2mod[conftestpath]
E KeyError:
local('SERVER\\programs\\python38\\lib\\site-packages\\numpy\\conftest.py')
During handling of the above exception, another exception occurred:
lib\site-packages\_pytest\config\__init__.py:446: in _importconftest
mod = conftestpath.pyimport()
lib\site-packages\py\_path\local.py:721: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E py._path.local.LocalPath.ImportMismatchError: ('numpy.conftest',
'X:\\Python38\\lib\\site-packages\\numpy\\conftest.py',
local('SERVER\\programs\\python38\\lib\\site-packages\\numpy\\conftest.py'))
During handling of the above exception, another exception occurred:
lib\site-packages\_pytest\runner.py:220: in from_call
result = func()
lib\site-packages\_pytest\runner.py:247: in
call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
lib\site-packages\_pytest\main.py:485: in collect
yield from self._collect(arg)
lib\site-packages\_pytest\main.py:512: in _collect
col = self._collectfile(pkginit, handle_dupes=False)
lib\site-packages\_pytest\main.py:581: in _collectfile
ihook = self.gethookproxy(path)
lib\site-packages\_pytest\main.py:424: in gethookproxy
my_conftestmodules = pm._getconftestmodules(fspath)
lib\site-packages\_pytest\config\__init__.py:420: in _getconftestmodules
mod = self._importconftest(conftestpath)
lib\site-packages\_pytest\config\__init__.py:454: in _importconftest
raise ConftestImportFailure(conftestpath, sys.exc_info())
E _pytest.config.ConftestImportFailure:
(local('SERVER\\programs\\python38\\lib\\site-packages\\numpy\\conftest.py'),
(,
ImportMismatchError('numpy.conftest',
'X:\\Python38\\lib\\site-packages\\numpy\\conftest.py',
local('SERVER\\programs\\python38\\lib\\site-packages\\numpy\\conftest.py')),
))
! Interrupted: 1 errors during collection
!
1 error in 16.39s
```
--
components: Library (Lib), Windows
messages: 350910
nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.realpath on Windows resolves mapped network drives
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue37993>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37189] PyRun_String not exported in python38.dll
Christoph Gohlke added the comment: `PyRun_String` was exported at least since `python23.dll`. Python.Net relies on it at <https://github.com/pythonnet/pythonnet/blob/master/src/runtime/runtime.cs#L858> -- ___ Python tracker <https://bugs.python.org/issue37189> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37189] PyRun_String not exported in python38.dll
New submission from Christoph Gohlke : While testing third party packages on Python 3.8.0b1 for Windows, I noticed that the `PyRun_String` function is no longer exported from `python38.dll`. Is this intentional? I can't see this mentioned at <https://docs.python.org/3.8/whatsnew/3.8.html> or <https://docs.python.org/3.8/c-api/veryhigh.html#c.PyRun_String> This change breaks existing code. But then `PyRun_String` is easy to replace with `PyRun_StringFlags`. -- components: Windows messages: 344905 nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: PyRun_String not exported in python38.dll versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37189> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35195] [Windows] Python 3.7 initializes LC_CTYPE locale at startup, causing performance issue on msvcrt isdigit()
Christoph Gohlke added the comment: This is still an issue with Python 3.8.0a4 -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue35195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35195] Pandas read_csv() is 3.5X Slower on Python 3.7.1 vs Python 3.6.7 & 3.5.2 On Windows 10
Christoph Gohlke added the comment: > test_isdigit.c: Can you try to call locale.setlocale(locale.LC_CTYPE, "") > before running your benchmark on Python 3.7.0? Yes, that slows down Python 3.7.0a3 to the 3.7.0a4 level. -- ___ Python tracker <https://bugs.python.org/issue35195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35195] Pandas read_csv() is 3.5X Slower on Python 3.7.1 vs Python 3.6.7 & 3.5.2 On Windows 10
Christoph Gohlke added the comment: I attached a minimal C extension module that can be used to demonstrate the performance degradation from Python 3.7.0a3 to 3.7.0a4. Build the extension with `py setup.py build_ext --inplace`, then run the following code on Python 3.7.0a3 to 3.7.0a4: ``` import time from test_isdigit import test_isdigit start_time = time.time() test_isdigit() print(time.time() - start_time) ``` On my Windows 10 Pro WS system, the timings are: Python 3.7.0a3: ~0.0156 Python 3.7.0a4: ~0.3281 I would expect that other locale aware functions in the UCRT are also affected but I have not tested that. -- ___ Python tracker <https://bugs.python.org/issue35195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35195] Pandas read_csv() is 3.5X Slower on Python 3.7.1 vs Python 3.6.7 & 3.5.2 On Windows 10
Change by Christoph Gohlke : Added file: https://bugs.python.org/file47929/setup.py ___ Python tracker <https://bugs.python.org/issue35195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35195] Pandas read_csv() is 3.5X Slower on Python 3.7.1 vs Python 3.6.7 & 3.5.2 On Windows 10
Change by Christoph Gohlke : Added file: https://bugs.python.org/file47928/test_isdigit.c ___ Python tracker <https://bugs.python.org/issue35195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35195] Pandas read_csv() is 3.5X Slower on Python 3.7.1 vs Python 3.6.7 & 3.5.2 On Windows 10
Christoph Gohlke added the comment:
> Can someone please try to write an example which only uses the stdlib?
The simplest is to compare performance of the
`windll.LoadLibrary('API-MS-WIN-CRT-STRING-L1-1-0.DLL')` function on Python
3.7.0a3 and 3.7.0a4, but that will mostly measure Python/ctypes overhead. I
will post a minimal C extension instead.
> What are these extensions? Where do them come from?
The `isdigit` function is from the UCRT. The `parsers` Cython/C extension is
part of the pandas wheel on PyPI. The context for this issue is at
https://github.com/pandas-dev/pandas/issues/23516
> I don't understand which "locale changes" you are talking about. You can
> change the locale using locale.setlocale().
The `UCRT.isdigit` function, when run on Python >=3.7.0a4, calls the
`_isdigit_l` function, which calls `_LocaleUpdate::_LocaleUpdate` (see the VS
profiler output).
--
nosy: +cgohlke
___
Python tracker
<https://bugs.python.org/issue35195>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33706] Segfault in command line processing due to buffer over-read
Change by Christoph Gohlke : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue33706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33706] Segfault in command line processing due to buffer over-read
New submission from Christoph Gohlke : When testing Python 3.7.0b5 x64 (and betas before) on Windows 10, I occasionally get segfaults when passing a program as string on the command line. The shortest command to reproduce this on my system is `python.exe -c 1` with heap detection turned on but that might not be reproducible on other systems. It turns out there is a buffer over-read when copying the `PyOS_optarg` string in `main.c`. The attached patch fixes the segfault on my system. -- files: master...cgohlke patch-1.diff keywords: patch messages: 318260 nosy: cgohlke priority: normal severity: normal status: open title: Segfault in command line processing due to buffer over-read versions: Python 3.7 Added file: https://bugs.python.org/file47628/master...cgohlke patch-1.diff ___ Python tracker <https://bugs.python.org/issue33706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31340] Use VS 2017 compiler for build
Christoph Gohlke <cgoh...@uci.edu> added the comment: > Have you confirmed that's a problem? No, I have not noticed any problems yet with with Python 3.7.0a3 and many extensions built with VS2017.5. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31340] Use VS 2017 compiler for build
Christoph Gohlke <cgoh...@uci.edu> added the comment: Since this has not been reverted/changed for 3.6.4 or 3.7.0a3, another potential issue arises: C extensions that are compiled with Visual Studio 2017 are linked to a newer version of vcruntime140.dll (latest is 14.12.25810, VS2017 15.5) than the DLL shipped with the CPython 3.6.4/3.7.0a3 installer (14.0.24210, VS2015 Update 3). There is no standard way C extensions that are compiled with VS2017 can load the correct/newer vcruntime140.dll. That said, I have not noticed any problems yet while testing with Python 3.7.0a3. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31340] Use VS 2017 compiler for build
Christoph Gohlke <cgoh...@uci.edu> added the comment: I build most of my binaries after calling the correct vcvarsall.bat so I did not notice until today, when I was trying to build outside that environment. Also, I misread your comment (https://bugs.python.org/issue31340#msg301538) earlier and did not worry at that time. I guess this might become a bigger issue once Appveyor switches to Python 3.6.3. Projects using Anaconda's prebuilt static libraries for v140 will fail to link. How about giving priority to VS 2015, i.e. "If you have VS 2015 then it will use that"? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31340] Use VS 2017 compiler for build
Christoph Gohlke <cgoh...@uci.edu> added the comment: I have Visual Studio 2015 and Visual Studio 2017 Community editions with latest patches installed. Building a minimal C extension on Python 3.6.3 with distutils now uses MSVC 14.11.25503. That is unexpected. When building complex extensions that link to static libraries that were built with MSVC 14.0, linking fails, e.g. when building Pillow: 'jpeg.lib' was created with an older compiler than other objects; rebuild old objects and libraries It looks like practically v141 is not binary compatible with v140. -- nosy: +cgohlke ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29943] PySlice_GetIndicesEx change broke ABI in 3.5 and 3.6 branches
Changes by Christoph Gohlke <cgoh...@uci.edu>: -- nosy: +cgohlke ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons
Christoph Gohlke added the comment: The applied patch breaks bdist_wininst installers for 64-bit Python. See <http://bugs.python.org/issue28680>. -- nosy: +cgohlke ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28680] bdist_wininst generated 64-bit executable looks for 3.5-32
Christoph Gohlke added the comment: The attached patch was tested with Pillow-3.4.2 on Python 3.6.0rc1, 32-bit and 64-bit. It would be nice to get this fixed in Python 3.5.3 and 3.6.0. -- components: +Windows keywords: +patch nosy: +paul.moore, steve.dower, tim.golden, zach.ware Added file: http://bugs.python.org/file45873/fix_issue28680.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28680] bdist_wininst generated 64-bit executable looks for 3.5-32
Christoph Gohlke added the comment: Pillow-3.4.2.win-amd64-py3.5.exe fails to install due to this. See <https://github.com/python-pillow/Pillow/issues/2285>. `MS_WIN64` is never defined at <https://hg.python.org/cpython/file/v3.5.2/PC/bdist_wininst/install.c#l157> because bdist_wininst does not depend on the Python headers. A possible fix is to use `_WIN64` instead of `MS_WIN64`. -- nosy: +cgohlke versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28114] Crash in unicodeobject.c find_maxchar_surrogates on python-3.6.0b1 for Windows
New submission from Christoph Gohlke:
Trying to build numpy-1.11.2rc1 wheels for Python 3.6.0b1 on Windows 10 with
`python.exe setup.py bdist_wheel`, python36.dll (32 and 64 bit) segfaults in
the `find_maxchar_surrogates` function. Some other packages built OK, e.g.
Cython, pyzmq and Pillow.
The crash is at
<https://hg.python.org/cpython/file/v3.6.0b1/Objects/unicodeobject.c#l1607>.
The call stack is attached.
Locals:
+ begin 0x00454c49464f5250 const wchar_t *
ch 1509860640 unsigned int
+ end 0x004550fc90512200 const wchar_t *
+ iter0x0259a500e7d8 L"\x2" const wchar_t *
+ maxchar 0x005a59fea520 {0} unsigned int *
+ num_surrogates 0x005a59fea528 {0} __int64 *
--
components: Interpreter Core, Unicode, Windows
files: callstack.txt
messages: 276189
nosy: cgohlke, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden,
zach.ware
priority: normal
severity: normal
status: open
title: Crash in unicodeobject.c find_maxchar_surrogates on python-3.6.0b1 for
Windows
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file44623/callstack.txt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1
Christoph Gohlke added the comment: FWIW, this could be a build issue: 1) `_ssl.OPENSSL_VERSION` for the 2.7.12rc1 amd64 binaries is "OpenSSL 1.0.2d 9 Jul 2015", not OpenSSL 1.0.2g as expected from the changelog at <https://hg.python.org/cpython/file/v2.7.12rc1/Misc/NEWS#l353>. 2) Rebuilding _ssl.pyd against openssl-1.0.2h fixes this issue for me (no crash). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1
Changes by Christoph Gohlke <cgoh...@uci.edu>: -- nosy: +cgohlke ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
Changes by Christoph Gohlke <cgoh...@uci.edu>: Added file: http://bugs.python.org/file40402/test_dll_load_failed.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
New submission from Christoph Gohlke: This issue was first mentioned at <http://bugs.python.org/issue24872#msg249591>. The attached script (test_dll_load_failed.py) builds up to 256 C extension modules and imports them. On Python 3.4.3 the script passes while on Python 3.5.0rc3 the script fails with: ``` Traceback (most recent call last): File "test_dll_load_failed.py", line 42, in import_module(name) File "X:\Python35\lib\importlib\__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 986, in _gcd_import File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 666, in _load_unlocked File "", line 577, in module_from_spec File "", line 903, in create_module File "", line 222, in _call_with_frames_removed ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. ``` Tested on Windows 7 and 10, 64 bit, with Python 3.5.0rc3, 32 and 64 bit. Due to this issue the "scientific stack" is practically unusable. For example, Pandas unit tests error or abort. In a Jupyter notebook, the following simple imports fail (using current builds from <http://www.lfd.uci.edu/~gohlke/pythonlibs/>): ``` In [1]: import matplotlib.pyplot import pandas import statsmodels.api --- ImportError Traceback (most recent call last) in () 1 import matplotlib.pyplot 2 import pandas > 3 import statsmodels.api X:\Python35\lib\site-packages\scipy\signal\__init__.py in () 276 # The spline module (a C extension) provides: 277 # cspline2d, qspline2d, sepfir2d, symiirord1, symiirord2 --> 278 from .spline import * 279 280 from .bsplines import * ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. ``` The cause of this issue is that as of Python 3.5.0rc1 C extension modules are linked statically to the multi-threaded runtime library (/MT) instead of the multi-threaded DLL runtime library (/MD). A process can not load more than 127 statically-linked CRT DLLs using LoadLibrary due to a limit of fiber-local storage (FLS) as mentioned in the following links: <http://stackoverflow.com/questions/1437422> <https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3546c3c4-1b36-4552-85c5-1b3ba860ee84> To put the 127 limit in perspective: the pywin32 package contains 51 C extension modules, pygame 36, scipy 65, and scikit-image 41. In addition to C extension modules, the 127 limit also applies to statically-linked CRT DLLs that are dynamically loaded via Ctypes or LoadLibrary. -- components: Extension Modules, Windows messages: 250169 nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.5.0rc3 on Windows can not load more than 127 C extension modules versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment:
Just to confirm: the following script fails with `ImportError: DLL load failed`
on Python 3.5.0rc2. It fails around the 120th extension. The script passes on
Python 3.4.3.
Also, Python 3.5.0rc2 (not Python 3.4.3) requires the `extra_postargs=['/DLL']`
argument to the `link_shared_lib` function, otherwise the linker fails with
`LINK : fatal error LNK1561: entry point must be defined`.
```
# test_issue24872.py
#
# Build up to 256 C extension modules and import them.
#
# On Python 3.5.0rc2 for Windows this raises "ImportError: DLL load failed:
# A dynamic link library (DLL) initialization routine failed."
#
# http://bugs.python.org/issue24872
import os
import sys
from importlib import import_module
from distutils import ccompiler
assert sys.platform == 'win32'
assert sys.version_info > (3, 2)
c_source = """/* Minimal Python 3 extension module */
#include "Python.h"
static struct PyModuleDef moduledef = {
PyModuleDef_HEAD_INIT, "%s", NULL, -1, NULL, NULL, NULL, NULL, NULL
};
PyMODINIT_FUNC PyInit_%s(void) { return PyModule_Create(); }
"""
cl = ccompiler.new_compiler()
for i in range(256):
name = '_tmp%.3i' % i
try:
os.remove(name+'.pyd')
except FileNotFoundError:
pass
with open(name+'.c', 'w') as fh:
fh.write(c_source % (name, name))
objects = cl.compile([name+'.c'])
cl.link_shared_lib(objects, output_libname=name, extra_postargs=['/DLL'],
export_symbols=["PyInit_"+name])
for ext in 'c', 'obj', 'exp', 'lib':
os.remove(name+'.'+ext)
os.rename(name+'.dll', name+'.pyd')
import_module(name)
```
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24872>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: > Do you know where that time is being spent? The incremental linker. > I'd guess it's probably O(N**2) with the number of obj file Doesn't seem so. For example the pyrxp 2.1 package contains only 23 C files and takes minutes to link. Most packages compile and link reasonably fast. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: I have now recompiled hundreds of Python packages and C/C++/Fortran libraries with the `/MT /GL /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` flags. Many packages test OK, only few crashes. Some more findings: The /MT flag forces to also statically link the Intel Fortran runtime library. Some libraries, e.g. OpenCV and Boost DLLs, can not be built with those flags (must be /MD). Although most packages pass unittests (numpy, scipy, matplotlib, etc.), running real world scripts, Pandas unit tests, or simple scripts in IPython notebook, fail semi-randomly with "ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed". This is reproducible with Python 3.5.0rc2, 64 and 32 bit, on Windows 10 and 7, 64 bit. It seems to be related to the number of extensions and DLLs loaded into the process. This needs more testing. Is there still a limit of how many DLLs, which are statically-linked to the CRT, can be loaded? <https://support.microsoft.com/en-us/kb/193462> <http://stackoverflow.com/questions/1437422> <https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3546c3c4-1b36-4552-85c5-1b3ba860ee84> -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Two findings regarding the new semi-static linking options: Distutils now creates libraries (.lib) that may not be readable by subsequent versions of Visual C++ https://msdn.microsoft.com/en-us/library/0zza0de8.aspx. Build times and static library sizes significantly increase to a point where it becomes impractical in some cases. For example, on my system, the zeromq package builds in 90 s on Python 3.4.3, while on Python 3.5rc1 it takes 470 s. Building HDF5 static libs with the new options takes 30 minutes (close to 100% CPU usage on 8 logical processors) compared to less than 5 minutes for the default options. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23606] ctypes.util.find_library(c) no longer makes sense
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23606 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: The matplotlib extensions compiled with Python 3.5.0rc1 (/MT) are larger than those compiled with 3.5.0b4 (/MD). The C++ runtime is statically linked. This seems undesirable for the same reasons the UCRT is not linked statically. In Introducing the Universal CRT [1] James McNellis strongly recommend against static linking of the Visual C++ libraries, for both performance and serviceability reasons. In Visual Studio 2015 RTM Now Available [2] the same author commented that one may deploy the Universal CRT app-locally. Do these comments not apply to CPython? [1] http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx [2] http://blogs.msdn.com/b/vcblog/archive/2015/07/20/visual-studio-2015-rtm-now-available.aspx -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Another /MT only issue: cryptography-1.0 and other libraries depending on openssl fail to link to static MT openssl-1.0.1p: cryptlib.obj : error LNK2001: unresolved external symbol __iob_func This can be fixed manually [1]. [1] http://openssl.6102.n7.nabble.com/Compiling-OpenSSl-Project-with-Visual-Studio-2015-td59416.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: FWIW, I rebuilt static libraries for zlib, jbig, jpeg, openjpeg, tiff, webp, lcms, and freetype with /MT flag (a tedious task) and was able to build matplotlib and Pillow using Python 3.5.0rc1. As expected there is no dependency on the vcruntime DLL. Even if everything is built with /MT and using UCRT, some extensions will still depend on version specific Visual C runtime DLLs, e.g. OpenMP, requiring users or distributors to install/bundle the VC runtime package. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Matplotlib and my own extensions are using C++ sources but do not depend on msvcp140.dll, just the ucrt. Am I missing something? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Thanks for going through that tedious process ~140 libraries to go. I hit the wall last night trying to build Boost DLLs. Boost's build tool b2 does not allow `link=shared runtime-link=static`, hence the `/MT /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` magic does not work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Thank you for looking into this. I just tried '/NODEFAULTLIB:msvcrt.lib' with Pillow and matplotlib but still get the linker errors: tiff.lib(jbig.obj) : error LNK2001: unresolved external symbol __imp_memchr freetype.lib(ftbase.obj) : error LNK2001: unresolved external symbol __imp_strrchr freetype.lib(truetype.obj) : error LNK2001: unresolved external symbol __imp_strstr freetype.lib(type1.obj) : error LNK2001: unresolved external symbol __imp_memchr freetype.lib(sfnt.obj) : error LNK2001: unresolved external symbol __imp_memchr Looks like I'll have to rebuild all the 3rd party libraries with '/MT' and link DLLs with '/NODEFAULTLIB:libucrt.lib ucrt.lib' to remove the dependency on vcruntimeXXX.dll. This change should probably be mentioned in the release notes. Maybe also bring it to the attention of Ilan Schnell (ilan) and Cournapeau David (cdavid) who build packages for Anaconda and Canopy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24798] _msvccompiler.py doesn't properly support manifests
Christoph Gohlke added the comment: It seems the switch to '/MT' was consciously intended as Python 3.5 itself is now compiled with '/MT'. For now I have patched _msvccompiler.py to use '/MD' and continue to link libraries built with '/MD'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24798 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24798] _msvccompiler.py doesn't properly support manifests
Christoph Gohlke added the comment: This change broke all my builds that link statically against 3rd party libraries built with the `/MD` flag. `/MD` was used at least since Python 2.3 and is the default for static libraries in Visual Studio 2015. Some of the broken builds: lxml, pillow, matplotlib, pygame, pycuda, pymssql, netcdf4, GDAL, psycopg2, pycurl, gmpy, and pyopenssl. All of these packages built OK with Python 3.5.0b4. The build errors are of this kind: `error LNK2001: unresolved external symbol __imp_memchr` `error LNK2001: unresolved external symbol __imp_strstr` The linker throws the following warning: `LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library` -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24798 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17213] ctypes loads wrong version of C runtime, leading to error message box from system
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17213 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18909] Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
Christoph Gohlke added the comment: Sorry, of course I meant 2**31. Thank you very much for your review! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18909] Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
Christoph Gohlke added the comment: @haypo: Thanks for fixing this so fast! Your changes work for me on win-amd64-py2.7 and py3.3. I am aware of two 3rd party C extensions that use the value of interpaddr(): https://github.com/python-imaging/Pillow/blob/master/_imagingtk.c#L40 https://github.com/matplotlib/matplotlib/blob/master/src/_tkagg.cpp#L233 Both parse the PyObject returned by interpaddr() into a Py_ssize_t variable using `PyArg_ParseTuple(PyObject*, n, Py_ssize_t)` and then cast the Py_ssize_t variable to a (TkappObject*). Can a PyLong with a value 3**31 be parsed into a Py_ssize_t on 32 bit platforms? Could this become a problem on systems where 32 bit processes can address more than 2 GB? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18909] Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
New submission from Christoph Gohlke:
Using 64 bit CPython 2.6.6, 2.7.5, 3.2.5 or 3.3.2, numpy 1.7.1 and matplotlib
1.3.0 on Windows 8 64 bit, the following script segfaults most of the times:
```
# allocate ~4GB fragmented data
import numpy
a = [numpy.zeros(2**i, 'uint8') for i in range(1, 31)]
b = [numpy.zeros(131072, 'float64') for i in range(2048)]
# plot using TkAgg
import matplotlib
matplotlib.use('TkAgg')
from matplotlib import pyplot
pyplot.plot()
pyplot.show()
```
```
Fatal Python error: Segmentation fault
Current thread 0x00036c5c:
File X:\Python33\lib\site-packages\matplotlib\backends\tkagg.py, line 17 in
blit
File X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py,
line 349 in draw
File X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py,
line 276 in resize
File X:\Python33\lib\tkinter\__init__.py, line 1475 in __call__
File X:\Python33\lib\tkinter\__init__.py, line 965 in update
File X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py,
line 574 in show
File X:\Python33\lib\site-packages\matplotlib\backend_bases.py, line 87 in
__call__
File X:\Python33\lib\site-packages\matplotlib\pyplot.py, line 145 in show
File tk_crash_win-amd64.py, line 14 in module
```
The pointer returned by Python's _tkinter.tkapp.interpaddr() is often wrong
because the 64 bit pointer is cast to 32 bit long and returned as PyInt.
Instead, the pointer should be cast to Py_ssize_t and returned as PyLong on
win-amd64.
The following patches for win-amd64-py2.7.5 and win-amd64-py3.3.2 fix the issue:
```
--- a/Modules/_tkinter.cSun Sep 01 19:06:35 2013 -0400
+++ b/Modules/_tkinter.cMon Sep 02 17:44:53 2013 -0700
@@ -2814,7 +2814,7 @@
if (!PyArg_ParseTuple(args, :interpaddr))
return NULL;
-return PyInt_FromLong((long)Tkapp_Interp(self));
+return PyInt_FromSsize_t((Py_ssize_t)Tkapp_Interp(self));
}
```
```
--- a/Modules/_tkinter.cSun Sep 01 19:03:41 2013 -0400
+++ b/Modules/_tkinter.cMon Sep 02 17:44:02 2013 -0700
@@ -2688,7 +2688,7 @@
if (!PyArg_ParseTuple(args, :interpaddr))
return NULL;
-return PyLong_FromLong((long)Tkapp_Interp(self));
+return PyLong_FromSsize_t((Py_ssize_t)Tkapp_Interp(self));
}
```
Updated _tkinter.pyd files are available at
http://www.lfd.uci.edu/~cgohlke/pythonlibs/#_tkinter.
--
messages: 196819
nosy: cgohlke
priority: normal
severity: normal
status: open
title: Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
type: crash
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18909
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18909] Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
Changes by Christoph Gohlke cgoh...@uci.edu: Added file: http://bugs.python.org/file31568/fix_tkapp_interpaddr-win-amd64-py3.3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18909] Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
Changes by Christoph Gohlke cgoh...@uci.edu: Added file: http://bugs.python.org/file31566/tkapp_interpaddr_crash_win-amd64.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18909] Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
Changes by Christoph Gohlke cgoh...@uci.edu: -- keywords: +patch Added file: http://bugs.python.org/file31567/fix_tkapp_interpaddr-win-amd64-py2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17289] readline.set_completer_delims() doesn't play well with others
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17289 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11835] python (x64) ctypes incorrectly pass structures parameter
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1425127] os.remove OSError: [Errno 13] Permission denied
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1425127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Changes by Christoph Gohlke cgoh...@uci.edu: -- versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file21034/msilib2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Christoph Gohlke cgoh...@uci.edu added the comment: Actually, PyQt4 was not a good example since it is not build using distutils. Pywin32 and wxPython extensions are the only ones on my system specifying a dependency on Common Controls or MFC. No dependencies other than CRT, MFC, and Common Controls are specified in any assemblies of over 1000 pyd and dll files in my Python27 directory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Christoph Gohlke cgoh...@uci.edu added the comment: The proposed patch was meant to be backwards compatible. Unconditionally removing the whole assembly/manifest from extensions could break extensions that have additional dependencies, such as MFC or Common Controls. PyQt4 extensions for example depend on Common Controls. Btw, there is a discussion at http://psycopg.lighthouseapp.com/projects/62710/tickets/20 and http://groups.google.com/group/modwsgi/browse_thread/thread/137f88ac6927df59 about the need to put the msvcr90 manifest back into the psycopg.pyd file in order to work properly under Apache's mod_wsgi, which is linked against msvcrt. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
New submission from Christoph Gohlke cgoh...@uci.edu: Running Tools/Scripts/2to3.py on Python 3.2rc3 or 2.7.1 for Windows on a file that contains a formfeed character (0x0C, FF) results in a truncated file. E.g. a file (attached) with the content print 1 FF print 2 is incorrectly refactored: @@ -1,4 +1,1 @@ -print 1 - - -print 2 +print(1) Python 2.6.6 and 3.1.3 correctly refactor the file: -print 1 +print(1) FF -print 2 +print(2) -- files: formfeedbug.py messages: 128885 nosy: cgohlke priority: normal severity: normal status: open title: 2to3 truncates files at formfeed character versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file20800/formfeedbug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
Changes by Christoph Gohlke cgoh...@uci.edu: -- components: +2to3 (2.x to 3.0 conversion tool) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Christoph Gohlke cgoh...@uci.edu added the comment: Curses binaries for Python 2.5, 2.6, 2.7, 3.1 and 3.2, win32 and win-amd64, are available at http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Christoph Gohlke cgoh...@uci.edu added the comment: Tkinter is not thread safe. You are changing UI elements from a thread that is not the main thread. Use a Queue as described at http://effbot.org/zone/tkinter-threads.htm. -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8275] callback function on win64 results in bad behavior. mem corruption?
Christoph Gohlke cgoh...@uci.edu added the comment: Thank you. The new patch works and it also fixes a crash of the python-2.5.4.amd64 interpreter at startup when ctypes 1.0.2 and pyreadline 1.6.2 are installed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9884] The 4th parameter of method always None or 0 on x64 Windows.
Christoph Gohlke cgoh...@uci.edu added the comment: The provided example has two problems: The DLL should be loaded as cdll, not windll. C_METHOD_TYPE4 uses c_int32 as parameter type while pyFunc4Type in testPy2.cpp uses LPVOID (64 bit on win-amd64). Even with those corrections the issue remains. -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9884] The 4th parameter of method always None or 0 on x64 Windows.
Christoph Gohlke cgoh...@uci.edu added the comment: The patch attached to #8275 fixes this issue and possibly also #9266. Tested with Python 2.7.1 64 bit on Windows 7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8275] callback function on win64 results in bad behavior. mem corruption?
Christoph Gohlke cgoh...@uci.edu added the comment: This patch fixes issue #9884 and possibly #9266. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8275] callback function on win64 results in bad behavior. mem corruption?
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10854] Output .pyd name in error message of ImportError when DLL load fails
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9015] array.array.tofile cannot write arrays of sizes 4GB, even compiled for amd64
Christoph Gohlke cgoh...@uci.edu added the comment: This seems to be related: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/7c913001-227e-439b-bf07-54369ba07994 -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Christoph Gohlke cgoh...@uci.edu added the comment: Creating bdist_msi installers with files such as 'aixc++' (containing '+'), '.buildinfo' (starting with '.'), and 'py.~1.5.~' (containing '~') currently also fails, even with the proposed patch. The revised patch should fix these cases and further improves the make_short function to generate short names compatible with NTFS. -- Added file: http://bugs.python.org/file19334/msilib.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Christoph Gohlke cgoh...@uci.edu added the comment: The revised patch for issue7639 now generates better short names for file names containing spaces, '+', and leading '.'. http://bugs.python.org/file19334/msilib.diff Test cases that could be added to MsilibTest.test_makeshort(): TEST : test TES~1.T : t.e.s.t TEST~1: .test TESTTEST : testtest TESTTE~1 : .testtest TESTTE~2 : test test TESTTE~3 : test test test AFILE~1.DOC : A file.doc THISIS~1.TXT : This is a really long filename.123.456.789.txt THISIS~1.789 : This is a really long filename.123.456.7890 TEST__~1 : test++ TE~1 : te++ TEST~1.__ : test.++ TEST.123 : test.123 TEST~1.123: test.1234 TEXT~1.123: text.1234 TESTTE~1.__ : testtest.++ FOO.TXT : foo.txt FOO2~1.TXT: foo.2.txt SOMELO~1.TXT : someLongName.txt SOMELO~2.TXT : someLongerName.txt PY~15~1.~ : py.~1.5.~ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6470] Tkinter import fails when running Python.exe from a network share
Christoph Gohlke cgoh...@uci.edu added the comment: Any chance to get this fixed in 2.7? On Windows, the bug prevents some popular applications and packages, such as pymol and matplotlib, to be used when installed on network shares, as is common practice in computer labs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6470] Tkinter import fails when running Python.exe from a network share
Christoph Gohlke cgoh...@uci.edu added the comment: Btw, this bug is also present in Python 3.1, of course when using tkinter instead of Tkinter. Here is how to reproduce the bug on your local system: Install python-2.7b2.msi into C:\Python27. Then open a command prompt with administrator privileges and start python.exe as follows: \\%COMPUTERNAME%\C$\Python27\python.exe -c from Tkinter import * Traceback (most recent call last): File string, line 1, in module File \\KLAPAUCIUS\C$\Python27\lib\lib-tk\Tkinter.py, line 38, in module import FixTk File \\KLAPAUCIUS\C$\Python27\lib\lib-tk\FixTk.py, line 56, in module for name in os.listdir(prefix): WindowsError: [Error 3] The system cannot find the path specified: 'UNC\\KLAPAUCIUS\\C$\\Python27\\tcl/*.*' It does not matter whether the network share is mapped as a drive letter or not, the Tkinter import fails with the same WindowsError. Also mounted network drives do have problems with UAC. A local Python installation can simply be copied to a network share and used from there from several other computers. All that eventually needs attention is the python*.dll, some scripts, and the MSVC runtime. I have deployed Python like this for years in several computer labs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6470] Tkinter import fails when running Python.exe from a network share
Christoph Gohlke cgoh...@uci.edu added the comment: The patch seems to deal with paths that have UNC in them; and the test seems not to. The UNCW path is a result of the call to ctypes.windll.kernel32.GetFinalPathNameByHandleW() in FixTk.py, which translates \\Server\Share\File paths to \\?\UNC\Server\Share\File. Simply removing the leading \\?\ from the UNCW path, as it is done in Python 2.6.5 and 2.7b2 FixTk.py, results in an invalid UNC\Server\Share\File path. The proposed patch removes UNC and prepends a \\, which gives a valid \\Server\Share\File path. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Christoph Gohlke cgoh...@uci.edu added the comment: A slightly different patch is attached to issue7639, which generates short names more similar to Windows/NTFS: http://bugs.python.org/file15898/msilib_make_short.diff Here are some short names created with the msilib_make_short patch, which are identical to the short names created by the Windows NTFS file system: foo.txt - FOO.TXT foo.2.txt - FOO2~1.TXT someLongName.txt- SOMELO~1.TXT someLongerName.txt - SOMELO~2.TXT For comparison, the msilib-2 patch generates these short names: foo.txt - FOO.TXT foo.2.txt - FOO.2.TXT- different from NTFS someLongName.txt- SOMELO~1.TXT someLongerName.txt - SOMELO~2.TXT -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6470] Tkinter import fails when running Python.exe from a network share
Christoph Gohlke cgoh...@uci.edu added the comment: This issue is also present in Python 2.7b2. The svn trunk requires a slightly different patch (attached). -- versions: +Python 2.7 Added file: http://bugs.python.org/file17304/Tkinter-import-UNCW-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Christoph Gohlke cgoh...@uci.edu added the comment: The bdist_wininst and DLL build issues also exist in Python 2.7b2. A patch against svn trunk is attached. The pywin32 v214 package fails as reported earlier when built with Python 2.7b2. It installs and functions when built with this patch. -- versions: +Python 2.7 Added file: http://bugs.python.org/file17286/msvc9compiler_stripruntimes_trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Christoph Gohlke cgoh...@uci.edu added the comment: I have some doubts about option #4: it is a very specific use case, and then the whole benefit of issue 4120 is lost Pythoncom are pywintypes are indeed special cases: Out of the 170 DLL files in my Python site-packages directory, these seem to be the only ones built with distutils. All other DLLs are apparently built without Python involvement using make, nmake, CMake, or Visual Studio and most of them contain embedded manifests, which is the default when using nmake, CMake, or Visual Studio. Practically, to make a standalone distribution of any Python 2.6/3.1 application with external DLL dependencies likely requires to provide external manifest files. The issue4120 patch does not change this situation and I don't see any sane way to patch Python/distutils that could. The main benefit of the issue4120 patch, as I see it, is that PYD files produced by distutils work in a standalone distribution without any further attention. Msvc9compiler_stripruntimes_revised.patch does not change this. My reasoning for this patch (besides fixing the bdist_wininst installer issue) was to allow the popular pywin32 package to build without changes, and offer a way for other extension packages to exclude manifests from DLL files if required (apparently not that common). Alternatively one could provide a mechanism to embed specific manifests into DLLs. Is that currently possible? Then pywin32 setup.py could be fixed. Why is putting a separate manifest file next to the DLL not an option? Because the pythoncom dll is currently installed into the Windows system directory. Putting manifest files there will pollute the system directory even more and possibly interfere with other system components if not done right (not tested). But again, pywin32 setup.py could be fixed to not install the DLL/manifest files into the system directory. Which Python packages other than pywin32 build DLL files via distutils? I don't know any. Can anyone provide a minimal setup.py script and C file that produces a DLL file for testing? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment: I mentioned the problem with pythoncom.dll and suggested a solution in issue7833. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7751] urllib.urlopen(///C|/foo/bar/spam.foo) IOError: [Errno 22]
Christoph Gohlke cgoh...@uci.edu added the comment: A testcase is attached. Information about the file URI scheme can be found at: http://en.wikipedia.org/wiki/File_URI_scheme http://tools.ietf.org/html/draft-hoffman-file-uri-03 http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx http://www.cs.tut.fi/~jkorpela/fileurl.html -- Added file: http://bugs.python.org/file16230/test_nturl2path.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Christoph Gohlke cgoh...@uci.edu added the comment: I thought one conclusion of the discussion on issue4120 was that any executable, which embeds Python and imports MSVCR9 dependent extensions, must now provide the manifest for the MSVCR9 runtimes, either embedded or as a separate file. See http://bugs.python.org/issue4120#msg94644 and responses. Why shouldn't this apply to wininst executables? Another observation: importing the winsound extension in the postinstall script works even though it also depends on MSVCR90.DLL. Winsound.pyd does not have an embedded manifest. It is linked with /MANIFEST:NO. Apparently there is a difference between an empty manifest and no manifest. How about a patch that does: 1) not embed any manifest into PYD files if the manifest contains only a single MSVCR90 dependentAssembly element. 2) remove the MSVCR90 dependentAssembly element from manifests embedded into PYD files if the manifest defines additional dependentAssembly elements (e.g. for MFC or Common Controls). This is essentially what the msvc9compiler_stripruntimes patch does now. 3) not embed manifests into any file (EXE, PYD, or DLL) if '/MANIFEST:NO' is defined in extra_link_args. Extension developers can then provide external manifest files. 4) not touch the default manifests embedded into EXE and DLL files. The msvc9compiler_stripruntimes currently produces DLLs that can not be used standalone, such as pythoncom26.dll from the pywin32 package (I can file a separate bug if requested). Pythoncom26.dll is meant to be placed in the system32 folder and to be used outside of a Python environment, i.e. from the Windows Scripting Host. Several pywin32 tests fail with the pythoncom26.dll built with the msvc9compiler_stripruntimes patch. Placing a MSVCR9 manifest file into the system32 folder next to the pythoncom26.dll is not an option. A tentative patch against the Python 2.6 branch is attached. I will test it further. (1) and (4) will solve the original pywin32 wininstaller problem without changing wininst.exe. As it is now the installer and some functionality of the pywin32 package will likely break if pywin32 is built on Python 2.6.5. -- Added file: http://bugs.python.org/file16121/msvc9compiler_stripruntimes_revised.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
New submission from Christoph Gohlke cgoh...@uci.edu:
Wininst-9.0.exe and wininst-9.0-amd64.exe are missing MSVCRT90 dependencies in
the embedded manifest.
While testing installers of pywin32 http://sourceforge.net/projects/pywin32/
version 214 built with Python 2.6.4 and the
msvc9compiler_stripruntimes_regexp2.diff patch from Issue4120
http://bugs.python.org/issue4120, I noticed that the post_install script
fails with an ImportError while trying to load extensions without embedded
MSVCRT90 manifest:
Traceback (most recent call last):
File string, line 601, in module
File string, line 311, in install
File string, line 149, in LoadSystemModule
ImportError: DLL load failed: The specified module could not be found.
The code that fails is:
mod = imp.load_module(modname, None, filename, ('.dll', 'rb',
imp.C_EXTENSION))
where modname='pywintypes' and filename points to an existing
'pywintypes26.dll' file.
The post_install script runs fine when executed from the main python.exe
interpreter.
A possible fix is to embed a MSVCRT90 dependency into wininst-9.0.exe and
wininst-9.0-amd64.exe using the following linker switches:
/MANIFESTDEPENDENCY:type='Win32' name='Microsoft.VC90.CRT'
version='9.0.21022.8' processorArchitecture='X86'
publicKeyToken='1fc8b3b9a1e18e3b'
/MANIFESTDEPENDENCY:type='Win32' name='Microsoft.VC90.CRT'
version='9.0.21022.8' processorArchitecture='amd64'
publicKeyToken='1fc8b3b9a1e18e3b'
See also http://msdn.microsoft.com/en-us/library/ew0y5khy.aspx
A patch against the Python 2.6 PCbuild\bdist_wininst.vcproj is attached. I
tested it with Python 2.6.4, 32 and 64 bit, and pywin32 214 installers built
with the following command:
python.exe setup.py bdist_wininst --user-access-control=auto
--install-script=wxpython_win_post_install.py
--
assignee: tarek
components: Distutils, Windows
files: bdist_wininst.vcproj.patch
keywords: patch
messages: 98694
nosy: cgohlke, tarek
severity: normal
status: open
title: Bdist_wininst installers fail to load extensions built with Issue4120
patch
versions: Python 2.6
Added file: http://bugs.python.org/file16086/bdist_wininst.vcproj.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7833
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Christoph Gohlke cgoh...@uci.edu added the comment:
The last line of my previous post should actually read
python.exe setup.py bdist_wininst
Anyway, here are three files (also attached) that can reproduce the problem:
1) setup.py
from distutils.core import setup, Extension
setup(name='testpyd', scripts = [testpyd_postinstall.py],
ext_modules=[Extension('testpyd', ['testpyd.c'],)],
options = {bdist_wininst: {install_script:
testpyd_postinstall.py, user_access_control: auto},})
2) testpyd.c
#include Python.h
PyMethodDef methods[] = {{NULL, NULL},};
void inittestpyd() {(void)Py_InitModule(testpyd, methods);}
3) testpyd_postinstall.py
#!python
import testpyd
Build the installer with python 2.6 and Issue4120 patch applied:
python setup.py bdist_wininst
Run the installer:
dist\testpyd-0.0.0.win32-py2.6.exe
The postinstall script fails with:
Traceback (most recent call last):
File string, line 1, in module
ImportError: DLL load failed: The specified module could not be found.
According to Sysinternals process monitor python26.dll is loaded from the
system32 directory, the testpyd.pyd extension is found at the right place, and
then the Windows path is searched in vain for MSVCR90.DLL.
Tested on Windows 7 Pro 64 bit.
--
Added file: http://bugs.python.org/file16088/test-bdist_wininst.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7833
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7751] urllib.urlopen(///C|/foo/bar/spam.foo) IOError: [Errno 22]
New submission from Christoph Gohlke cgoh...@uci.edu:
On Windows 7, Python 2.6 raises an IOError when opening a valid file URL with
urllib.urlopen(). A patch to the nturl2path.url2pathname function is attached.
It replaces '%7C' by '|' in the url at the top of the url2pathname function.
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import sys, urllib
fname = sys.executable
fname
'x:\\python26\\python.exe'
fname = file:/// + fname.replace('\\', '/').replace(':', '|')
fname
'file:///x|/python26/python.exe'
urllib.urlopen(fname)
Traceback (most recent call last):
File stdin, line 1, in module
File x:\python26\lib\urllib.py, line 87, in urlopen
return opener.open(url)
File x:\python26\lib\urllib.py, line 206, in open
return getattr(self, name)(url)
File x:\python26\lib\urllib.py, line 468, in open_file
return self.open_local_file(url)
File x:\python26\lib\urllib.py, line 482, in open_local_file
raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 22] The filename, directory name, or volume label syntax is
incorrect: '\\x|\\python26\\python.exe'
--
components: Library (Lib), Windows
files: url2pathname.patch
keywords: patch
messages: 98119
nosy: cgohlke
severity: normal
status: open
title: urllib.urlopen(///C|/foo/bar/spam.foo) IOError: [Errno 22]
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15965/url2pathname.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7751
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Christoph Gohlke cgoh...@uci.edu added the comment: I can confirm this issue. It prevents building a IPython msi installer on Python 2.6 for Windows. A patch to the Directory.make_short function in msilib\__init__.py is attached. It falls back to generating prefix~pos filenames when a short name is already taken and also generates short names more similar to Windows/NTFS. -- keywords: +patch nosy: +cgohlke Added file: http://bugs.python.org/file15898/msilib_make_short.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment: My last comment was merely reporting that this patch can break MinGW based build processes. It did surprise some developers that their programs embedding matplotlib, which is now build with the MSVC9 patch, stopped working. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment:
Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
for MinGW users. The following C program is using the Python C API to
import the testpyd extension generated by testpyd.py. When compiled with
MinGW, the program fails with ImportError: DLL load failed:... if the
PYD extension is compiled with MSVC9 and the patch is applied. The
program works if 1) it is compiled with MSVC9, or 2) the testpyd
extension is build without the patch, or 3) the files
Microsoft.VC90.CRT.manifest and msvcr90.dll are placed next to the
executable and the manifest is also embedded into the executable (e.g.
using mt.exe).
/* Import the testpyd.pyd module. */
#include Python.h
int main(void) {
Py_Initialize();
{
PyObject *p = PyImport_ImportModule(testpyd);
}
Py_Finalize();
return 0;
}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment: There are two levels of testing. First, on a Windows development system with Visual Studio 2008, Python 2.6.2+, and the msvc9compiler_stripruntimes_regexp2.diff patch applied, verify that the embedded manifest in distutil generated PYD extension files is stripped of the WinSxS VC.CRT dependency and that the extensions can still be imported. The attached script (testpyd.py) builds a minimal extension (testpyd.pyd), searches for the WinSxS VC.CRT dependency within the pyd file, and imports the extension. The script should run without exception. Second, verify that distutil generated PYD extensions can also be imported on a test system, which has no Visual Studio 2008 runtime installed in %WINDIR%\WinSxS: Install Windows XP SP3, preferably in a virtual machine. Do not install any additional programs or patches, which might install the Visual Studio 2008 runtime. Then install Python 2.6.2+ using the Install just for me option. Try import the testpyd extension built on the development system: run python.exe -c 'import testpyd' in a directory containing the testpyd.pyd file (not the Python installation directory containing python.exe). This should work without exception. Importing the testpyd extension built without the patch fails on the test system: Traceback (most recent call last): File stdin, line 1, in module ImportError: DLL load failed: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. Tested with Python 2.6.3 for Windows 32-bit. -- Added file: http://bugs.python.org/file15161/testpyd.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment: This patch also removes empty dependentAssembly elements after removing the VC.CRT assemblyIdentity element. It seems not enough to just place the Microsoft.VC90.CRT.manifest and VC runtime DLL files into the Python folder. On a system without the VC runtime installed in winsxs, trying to import a pyd module build without the patch fails with ImportError: DLL load failed: Import works when 1) the manifest and VC runtime DLLs are also placed in the same folder as the pyd file, or 2) the Microsoft Visual C++ 2008 redistributable package is installed, or 3) the pyd file is build with the patch installed. Tested with Windows XP SP3, Python 2.6.3, matplotlib 0.99.1, Visual Studio 2008 SP1. -- Added file: http://bugs.python.org/file15113/msvc9compiler_stripruntimes_regexp2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment: The attached patch uses a regular expression. -- Added file: http://bugs.python.org/file15072/msvc9compiler_stripruntimes_regexp.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Christoph Gohlke cgoh...@uci.edu added the comment: There are two easy to fix issues with the msvc9compiler_stripruntimes.diff patch: 1) the dependency for 64-bit VC90.CRT is not removed and 2) the VC90.CRT dependency is removed also from executables, which will fail to run. A revised patch is attached. This is used to build the Matplotlib binaries for Windows and also works for numpy, pygame and PIL. -- nosy: +cgohlke Added file: http://bugs.python.org/file15026/msvc9compiler_stripruntimes_revised.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6470] Tkinter import fails when running Python.exe from a network share
New submission from Christoph Gohlke cgoh...@uci.edu: On Windows Vista 64-bit, when running Python 2.6.2 (32 or 64 bit) from a network share, e.g. \\Server\Share\python26\python.exe, importing Tkinter fails with WindowsError: [Error 3] The system cannot find the path specified. See session output below for traceback. This is due to incomplete support for long UNC (UNCW) paths such as \\?\UNC\Server\Share\File in FixTk.py. The attached patch solves this issue. -Christoph C:\\\server\share\python26\python.exe Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. from Tkinter import * Traceback (most recent call last): File stdin, line 1, in module File \\server\share\python26\lib\lib-tk\Tkinter.py, line 38, in module import FixTk File \\server\share\python26\lib\lib-tk\FixTk.py, line 59, in module for name in os.listdir(prefix): WindowsError: [Error 3] The system cannot find the path specified: u'UNC\\server\\share\\Python26\\tcl\\*.*' -- components: Tkinter, Windows files: Tkinter-import-UNCW.patch keywords: patch messages: 90457 nosy: cgohlke severity: normal status: open title: Tkinter import fails when running Python.exe from a network share type: crash versions: Python 2.6 Added file: http://bugs.python.org/file14488/Tkinter-import-UNCW.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
