[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> added the comment: > Only a PR for master is needed. Serhiy Storchaka, thanks for advice, I cancelled unnecessary PRs. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> added the comment: Pull-requests for 2.7, 3.7 and master submitted on github, all tests look passed, so Python dev-team, please, take a look. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Change by Vitaly Murashev <murashev_vit...@mail.ru>: -- versions: +Python 2.7, Python 3.7, Python 3.8 -Python 3.3, Python 3.4 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> added the comment: > Vitaly, in the future please use gender-neutral words Mariatta, OK, got it, I am sorry for that. I am not a native speaker. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> added the comment: Guys, a couple questions ... I want to suggest new patches for python3.7 and python2.7 with regression tests included What is proper way to do it now, in year 2018 ? May I do it on github.com ? Should I submit new issue for that there ? Or am I still supposed to attach new patches here - on bugs.python.org ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Vitaly Murashev added the comment: > And why not open MS_WIN64 to any Windows compiler It would be very good idea Patches suggested here are just the drafts which just work. Actually I don't believe they will be accepted, so just dropped here for history -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28270] [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
Vitaly Murashev added the comment: We (crystax.net) are building Python for Windows completely by cmake and MinGW using PC/pyconfig.h without any configure scripts -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28271] [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44814/callproc.c.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28271] [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW
New submission from Vitaly Murashev: Structured exception handling not supported by MinGW, and as a result file 'Modules/_ctypes/callproc.c' is not compilable by MinGW without patching As I know the patch was initially introduced in Google's repo, and fixed file 'callproc.c' now can be found here https://android.googlesource.com/platform/external/python/+/upstream-2.7/Modules/_ctypes/callproc.c Since I am sure that it is waste of time to wait while Googe suggest the patch in cpython upstream, I'm just injected Google's patch to the recent python version. So suggested patch (for 3.5.2 and 2.7.12) is just an adoption of Google's patch to the recent cpython versions. -- components: Build, ctypes files: callproc.c.3.5.mingw.patch keywords: patch messages: 277370 nosy: vmurashev priority: normal severity: normal status: open title: [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW type: compile error Added file: http://bugs.python.org/file44813/callproc.c.3.5.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28270] [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
New submission from Vitaly Murashev: 'posixmodule.c' is written pretty well, but some important MinGW realated macro are missed. And as a result an attempt to complile Modules/posixmodule.c by MinGW fails. So suggested patch (for 3.5.2 and 2.7.12) just turns on missed MinGW related macro -- components: Build files: posixmodule.c.3.5.mingw.patch keywords: patch messages: 277367 nosy: vmurashev priority: normal severity: normal status: open title: [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed type: compile error Added file: http://bugs.python.org/file44811/posixmodule.c.3.5.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28270] [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44812/posixmodule.c.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: -- type: -> crash ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: -- type: -> compile error ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Vitaly Murashev added the comment: Patch suggested here is actually the most trivial as it could be. And at the same time we (crystax.net) can prove that after this patch Python being compiled by MInGW for 64-bit Windows actually works well. There are other minor fixes but this one is the most important and again - is really trivial -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44809/dynload_win.c.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
New submission from Vitaly Murashev:
Attempt to complile Python/dynload_win.c by MinGW fails
due to static reimplementation of strcasecmp function in this file:
---
/* Case insensitive string compare, to avoid any dependencies on particular
C RTL implementations */
static int strcasecmp (char *string1, char *string2)
{
int first, second;
do {
first = tolower(*string1);
second = tolower(*string2);
string1++;
string2++;
} while (first && first == second);
return (first - second);
}
---
And this reimplementation clashed with native declaration of strcasecmp()
which one is a part of MinGW runtime
So suggested patch (for 3.5.2 and 2.7.12)
just disables static reimplementation of strcasecmp for MinGW
--
components: Build
files: dynload_win.c.3.5.mingw.patch
keywords: patch
messages: 277362
nosy: vmurashev
priority: normal
severity: normal
status: open
title: [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Added file: http://bugs.python.org/file44808/dynload_win.c.3.5.mingw.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28269>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44806/pyconfig.h.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
New submission from Vitaly Murashev: Hi,here the issue: We (crystax.net) use custom builds of cpython, which for windows are compiled by MinGW with pyconfig.h taken from PC/pyconfig.h And for 32-bit Windows everything works well, but for 64-bit Windows - doesn't. The root cause of this issue is actauly very simple: Python code for windows is very sensitive on properly defined macro MS_WIN32/MS_WIN64 And while MS_WIN32 is predefined unconditionally in PC/pyconfig.h, the MS_WIN64 is defined only in conjunction with _MSC_VER, like #ifdef _MSC_VER ... #ifdef _WIN64 #define MS_WIN64 #endif ... #endif /* _MSC_VER */ So suggested patch (for 3.5.2 and 2.7.12) just appropriately define MS_WIN64 for MinGW -- components: Build, Windows files: pyconfig.h.3.5.mingw.patch keywords: patch messages: 277352 nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware priority: normal severity: normal status: open title: [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h Added file: http://bugs.python.org/file44805/pyconfig.h.3.5.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25155] datetime.datetime.now() raises
New submission from Vitaly Murashev: Current time on my machine with Windows7x64 is set to year 2045 for test purposes. Since Python3.5(amd64) I have an OverflowError when I am trying to call datetime.datetime.now() It looks like a regress since there was no such error on Python3.4.3 Could anyone please give me a note, whether it would be reasonable for me to wait for a patch in Python3.5.x, or such behavior is common since 3.5 and should not use it in my 'strange' case at all ? A bit of details: Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() Traceback (most recent call last): File "", line 1, in OverflowError: timestamp too large to convert to C _PyTime_t >>> Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() datetime.datetime(2045, 4, 2, 2, 42, 8, 359375) >>> -- components: Interpreter Core, Windows messages: 250914 nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware priority: normal severity: normal status: open title: datetime.datetime.now() raises type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service
New submission from Vitaly Murashev:
[Affects Windows only]
Brief description (after analysis in debugger):
Py_InitializeEx fails inside internal call:
1.
if (initstdio() 0)
Py_FatalError(
Py_Initialize: can't initialize sys standard streams);
2. inside initstdio():
if (!is_valid_fd(fd)) {
std = Py_None;
Py_INCREF(std);
}
else {
// === is_valid_fd() passed and we come here
std = create_stdio(iomod, fd, 0, stdin, encoding, errors);
if (std == NULL)
goto error; // === this goto leads to fatal error
3.
is_valid_fd(int fd) /// = JFI: fd=0
{
int dummy_fd;
if (fd 0 || !_PyVerify_fd(fd))
return 0;
dummy_fd = dup(fd); /// == dup() WORKS well
if (dummy_fd 0)
return 0;
close(dummy_fd);
return 1;
}
4.
Let's Look whats going in create_stdio():
Modules\_io\fileio.c
static int
fileio_init(PyObject *oself, PyObject *args, PyObject *kwds)
{ ...
if (fd = 0) {
if (check_fd(fd))
goto error;/// = fail is here
5. Let's have a look at check_fd():
static int
check_fd(int fd)
{
#if defined(HAVE_FSTAT) /// = yes, it is defined for Windows
struct stat buf;
if (!_PyVerify_fd(fd) || (fstat(fd, buf) 0 errno == EBADF)) {
PyObject *exc;
char *msg = strerror(EBADF);
exc = PyObject_CallFunction(PyExc_OSError, (is),
EBADF, msg);
PyErr_SetObject(PyExc_OSError, exc);
Py_XDECREF(exc);
return -1;
}
#endif
return 0;
}
--
components: IO, Interpreter Core, Windows
messages: 246199
nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware
priority: normal
severity: normal
status: open
title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service
type: crash
versions: Python 3.4, Python 3.5, Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24561
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service
Vitaly Murashev added the comment: patch suggested -- keywords: +patch Added file: http://bugs.python.org/file39854/pythonrun.c.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being called from winnt-service
Changes by Vitaly Murashev murashev_vit...@mail.ru: -- title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service - [VS2013] Py_InitializeEx causes fatal error being called from winnt-service ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service
Vitaly Murashev added the comment: More details: previously Python3.4.3 was compiled in my environment using compiler from VisualStudio-2005 and everything worked well. The crash has come right after changing compiler to the one from VisualStudio-2013 So something definitely changed inside Microsoft runtime implementation. For unknown reason when winnt-service is running, its std file handles 0,1,2 can be duplicated using dup() but fstat() fails -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows
New submission from Vitaly Murashev: When I use 'zip' command-line tool on my Ubuntu 10.04 to pack a directory in zip-archive, it internally assigns '0x41ed0010' attributes for it. 0x41ed0010 = 0x41ed 0xfff + 0x0010 Where: 0x41ed - unix attributes (40755) 0x0010 - means # MS-DOS directory flag At the same time zipfile.py doesn't provide MS-DOS directory flag. It seems be a good idea to do it. Patch suggested over 3.3.3 code-base. -- components: Library (Lib) files: zipfile.py.diff keywords: patch messages: 213416 nosy: vmurashev priority: normal severity: normal status: open title: [zipfile.py]: Make zip directory attributes more friendly for MS-Windows type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34399/zipfile.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20912 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: patch suggested (over 3.3.0 code base). Without patch test fails, with patch - passed -- components: -Library (Lib) keywords: +patch Added file: http://bugs.python.org/file31781/zipimport.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18307 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: unit-test attached. There are 3 tests inside it: 2 failed, 1 succeeded. According to this test results it becomes clear that specified issue is reproduced only with zip modules which contain precompiled bytecode inside (pyc-files) -- Added file: http://bugs.python.org/file31451/test_zipimport_co_filename.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
New submission from Vitaly Murashev: Cannot compile _ssl module when openssl version 1.0 and it is configured with turned on macro OPENSSL_NO_DEPRECATED Everything looks like in recent versions of openssl routine 'CRYPTO_set_id_callback' has gone away. Patch suggested. -- components: Build files: ssl.patch keywords: patch messages: 195602 nosy: vmurashev priority: normal severity: normal status: open title: Cannot compile _ssl.c using openssl 1.0 type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file31368/ssl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
New submission from Vitaly Murashev: Recently I found out that it not possible to debug python code if it is a part of zip-module. Python version being used is 3.3.0 Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to start debugging and give the following warning: --- pydev debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute) pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints. --- So I started my own investigation of this issue and results are the following. At first I took traditional python debugger 'pdb' to analyze how it behaves during debug of zipped module. 'pdb' showed me some backtaces and filename part for stack entries looks malformed. I expected something like 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py' but realy it looks like 'full-path-to-current-dir/subdir/test_module.py' Source code in pdb.py and bdb.py (which one are a part of python stdlib) gave me the answer why it happens. The root cause are inside Bdb.format_stack_entry() + Bdb.canonic() Please take a look at the following line inside 'format_stack_entry' method: filename = self.canonic(frame.f_code.co_filename) For zipped module variable 'frame.f_code.co_filename' holds _relative_ file path started from the root of zip archive like 'subdir/test_module.py' And as relult Bdb.canonic() method gives what we have - 'full-path-to-current-dir/subdir/test_module.py' --- Looks like it is a bug in: - in python core subsystem which one is responsible for loading zipped modules - or in pdb debugger -- components: Interpreter Core, Library (Lib) messages: 191907 nosy: vmurashev priority: normal severity: normal status: open title: Relative path in co_filename for zipped modules type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
