Repository navigation
Crash on Windows if Python runs from a directory with umlauts #45683
Description
| BPO | 1342 |
|---|---|
| Nosy | @gvanrossum, @loewis, @amauryfa, @pitrou, @tiran |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/amauryfa'
closed_at = <Date 2008-06-11.18:26:49.274>
created_at = <Date 2007-10-27.03:40:35.693>
labels = ['interpreter-core', 'type-crash']
title = 'Crash on Windows if Python runs from a directory with umlauts'
updated_at = <Date 2008-06-11.18:26:43.466>
user = 'https://github.com/tiran'bugs.python.org fields:
activity = <Date 2008-06-11.18:26:43.466>
actor = 'amaury.forgeotdarc'
assignee = 'amaury.forgeotdarc'
closed = True
closed_date = <Date 2008-06-11.18:26:49.274>
closer = 'amaury.forgeotdarc'
components = ['Interpreter Core']
creation = <Date 2007-10-27.03:40:35.693>
creator = 'christian.heimes'
dependencies = []
files = ['8633', '8741', '10575']
hgrepos = []
issue_num = 1342
keywords = ['patch']
message_count = 17.0
messages = ['56841', '56852', '56853', '56865', '56979', '57094', '57456', '57466', '57474', '57681', '57687', '57698', '66441', '66460', '66462', '67915', '68006']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'loewis', 'nnorwitz', 'amaury.forgeotdarc', 'pitrou', 'christian.heimes', 'rasky']
pr_nums = []
priority = 'critical'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue1342'
versions = ['Python 3.0']
Activity
tiran commentedon Oct 27, 2007
Python 3.0 doesn't run from a directory with umlauts and possible other
non ASCII chars.
I renamed my development folder from C:\dev\ to c:\test äöüß name\.
Python crashes after a few moments before it can reach its shell.
value=0x00a0b8a0) Zeile 56 + 0xb Bytes C
python30.dll!PyErr_SetString(_object * exception=0x1e1b9888, const
char * string=0x1e18c358) Zeile 77 + 0xd Bytes C
python30.dll!find_module(char * fullname=0x0021fcc0, char *
subname=0x00000000, _object * path=0x00000000, char * buf=0x0021fb70,
unsigned int buflen=257, _iobuf * * p_fp=0x0021fb64, _object * *
p_loader=0x0021fb68) Zeile 1228 + 0x10 Bytes C
python30.dll!import_submodule(_object * mod=0x1e1c6a88, char *
subname=0x0021fcc0, char * fullname=0x00000000) Zeile 2313 + 0x27 Bytes C
python30.dll!load_next(_object * mod=0x1e1c6a88, _object *
altmod=0x1e1c6a88, char * * p_name=0x00000000, char * buf=0x0021fcc0,
int * p_buflen=0x0021fcbc) Zeile 2127 + 0x15 Bytes C
python30.dll!import_module_level(char * name=0x00000000, _object *
globals=0x00000000, _object * locals=0x1e069ec3, _object *
fromlist=0x00000000, int level=0) Zeile 1908 + 0x1a Bytes C
python30.dll!PyImport_ImportModuleLevel(char * name=0x1e184b04,
_object * globals=0x00000000, _object * locals=0x00000000, _object *
fromlist=0x00000000, int level=0) Zeile 1979 + 0x18 Bytes C
python30.dll!_PyCodecRegistry_Init() Zeile 841 + 0x12 Bytes C
python30.dll!PyCodec_LookupError(const char * name=0x00000000) Zeile
436 + 0xc Bytes C
python30.dll!unicode_decode_call_errorhandler(const char *
errors=0x00000000, _object * * errorHandler=0x00000009, const char *
encoding=0x1e1979ec, const char * reason=0x00000000, const char * *
input=0x0021fe80, const char * * inend=0x0021fe84, int *
startinpos=0x0021fe6c, int * endinpos=0x0021fe68, _object * *
exceptionObject=0x00000000, const char * * inptr=0x0021fe90, _object * *
output=0x0021fe70, int * outpos=0x0021fe88, unsigned short * *
outptr=0x0021fe74) Zeile 1384 + 0xa Bytes C
python30.dll!PyUnicodeUCS2_DecodeUTF8Stateful(const char *
s=0x1e1dd010, int size=48, const char * errors=0x00000000, int *
consumed=0x00000000) Zeile 1967 + 0x47 Bytes C
python30.dll!PyUnicodeUCS2_FromStringAndSize(const char *
u=0x1e1dd008, int size=48) Zeile 464 + 0xb Bytes C
python30.dll!PyUnicodeUCS2_FromString(const char * u=0x1e1dd008)
Zeile 482 + 0x7 Bytes C
python30.dll!_PySys_Init() Zeile 1084 + 0xb Bytes C
python30.dll!Py_InitializeEx(int install_sigs=1) Zeile 220 C
python30.dll!Py_Initialize() Zeile 292 + 0x7 Bytes C
python30.dll!Py_Main(int argc=2, char * * argv=0x00000001) Zeile 432 C
tiran commentedon Oct 27, 2007
The patch fixes parts of the problem. At least Python doesn't crash any
more when run from a directory with non ASCII chars. It just fails with
an import error in initstdio().
tiran commentedon Oct 27, 2007
I've added a fprintf(stderr, "%s", path) to makepathobject(). I suspect
that PC/getpathp.c doesn't handle non ASCII chars correctly. It's using
char instead of w_char all over the place. Could that be related to the
issue, Neal?
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
c:\testäöü\PCBuild8\win32release>set PYTHONPATH=c:\testäöü\Lib
c:\testäöü\PCBuild8\win32release>python
c:\testõ÷³\Lib;c:\testõ÷³\PCBuild8\win32release\python30.zip;c:\testõ÷³\DLLs;c:\
testõ÷³\lib;c:\testõ÷³\lib\plat-win;c:\testõ÷³\lib\lib-tk;c:\testõ÷³\PCBuild8\wi
n32releaseFatal Python error: Py_Initialize: can't initialize sys
standard strea
ms
object : ImportError('No module named encodings.utf_8',)
type : ImportError
refcount: 4
address : 00A43540
lost sys.stderr
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
tiran commentedon Oct 27, 2007
The bug is related to http://bugs.python.org/issue1262
tiran commentedon Oct 30, 2007
Hi Martin!
Thomas Wouters said on #python that you have the Windows Fu to fix the
problem. Parts of the Python API for file paths, sys.path and os.environ
have to be reimplemented using the wide char API.
tiran commentedon Nov 4, 2007
I've checked in part of the patch in r58837. It doesn't solve the
problem but at least it prevents Python from seg faulting on Windows.
tiran commentedon Nov 13, 2007
I like to move _PyExc_Init() before _PySys_Init() and set sys.prefix,
exec_prefix and executable with PyUnicode_DecodeFSDefault().
Without the changes Python is seg faulting on Windows when the path
contains non ASCII chars. With the patch it is failing with a fatal
error which is a tiny bit nicer.
gvanrossum commentedon Nov 13, 2007
If this doesn't cause any problems on other platforms, go for it.
tiran commentedon Nov 14, 2007
I'm setting the priority to normal. The issue isn't resolved but it's
not critical for the next alpha release. By the way what's your ETA for
the next alpha, Guido?
amauryfa commentedon Nov 20, 2007
Assign to myself.
Among the things to do, use Py_FileSystemDefaultEncoding (=mbcs on
Windows) to encode sys.path items; likewise in NullImporter_init and
other functions.
So many places to change, we need serious testcases.
loewis commentedon Nov 20, 2007
Please don't use the FileSystemEncoding on Windows for sys.path items.
Instead, it should use the wide API to perform all system calls. Py3k
shouldn't ever use the file system encoding for anything on Windows.
amauryfa commentedon Nov 20, 2007
Agreed. I will try to stay with PyObjects* until really needed by a system call.
tiran commentedon May 8, 2008
I'm increasing the severity of the bug. It's a still a major show
stopper for non-English Windows users. For example see bpo-2780
pitrou commentedon May 9, 2008
There are some problems under Linux too:
pitrou commentedon May 9, 2008
See bpo-2798 for the non-Windows case, with a patch.
amauryfa commentedon Jun 10, 2008
Here is a quick fix, that decodes filenames using
Py_FileSystemDefaultEncoding, to let the release pass.
I am still working on a version that keep PyObjects* as long as
possible, but it will be a major change.
amauryfa commentedon Jun 11, 2008
Fixed as r64126, using Py_FileSystemDefaultEncoding.
I close this issue, and open bpo-3080 to rewrite all functions in
import.c with full unicode in mind.