[issue1754] WindowsError messages are not properly encoded
Romulo A. Ceccon added the comment: > I think WindowsError's message should be English like other errors. > FormatMessageW() function can take dwLanguageId parameter. > So I think Python should pass `MAKELANGID(LANG_ENGLISH, > SUBLANG_ENGLISH_US)` to the parameter. On a non-english system FormatMessageW fails with ERROR_RESOURCE_LANG_NOT_FOUND (The specified resource language ID cannot be found in the image file) when called with that parameter. -- ___ Python tracker <http://bugs.python.org/issue1754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754] WindowsError messages are not properly encoded
New submission from Romulo A. Ceccon:
The message for WindowsError is taken from the Windows API's
FormatMessage() function, following the OS language. Currently Python
does no conversion for those messages, so non-ASCII characters end up
improperly encoded in the console. For example:
>>> import os
>>> os.rmdir('E:\\temp')
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 41] A pasta nÒo estß vazia: 'E:\\temp'
Should be: "A pasta não está vazia" [Folder is not empty].
Python could check what is the code page of the current output interface
and change the message accordingly.
--
components: Windows
messages: 59441
nosy: Romulo A. Ceccon
severity: minor
status: open
title: WindowsError messages are not properly encoded
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1754>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754] WindowsError messages are not properly encoded
Romulo A. Ceccon added the comment: "... but the error message must be converted to str early (i.e when building the Exception)." Wouldn't that create more problems? What if somebody wants to intercept the exception and do something with it, like, say, redirect it to a log file? The programmer must, then, be aware of the different encoding. I thought about keeping the exception message in Unicode and converting it just before printing. Is that possible for Python 2.x? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1754> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times
New submission from Romulo A. Ceccon:
I have patched (see attachment) Python 2.7.4 (as available for download at
python.org/download) to disable initialization of Unicode (an embeded system
requirement) and now it segfaults with the following program:
#include
int main(int argc, char** argv)
{
int i;
Py_NoSiteFlag = 1;
Py_SetProgramName(argv[0]);
for (i = 0; i < 3; i++)
{
printf("run no. %d\n", i);
Py_Initialize();
Py_Finalize();
}
return 0;
}
The problem appears to be related with the reference count of the empty tuple.
I've also applied the following patch in Objects/tupleobject.c to help diagnose
the problem:
@@ -928,6 +928,8 @@ PyTuple_Fini(void)
#if PyTuple_MAXSAVESIZE > 0
/* empty tuples are used all over the place and applications may
* rely on the fact that an empty tuple is a singleton. */
+printf("free_list[0]->ob_refcnt before XDECREF: %d\n",
+free_list[0]->ob_refcnt);
Py_XDECREF(free_list[0]);
free_list[0] = NULL;
*Without* the patch for Python/pythonrun.c the program produces the following
results under Ubuntu 13.04 x64:
run no. 0
free_list[0]->ob_refcnt before XDECREF: 58
run no. 1
free_list[0]->ob_refcnt before XDECREF: 57
run no. 2
free_list[0]->ob_refcnt before XDECREF: 57
Note the strange ref count of the empty tuple (free_list[0]). Now, *with* the
patch, the application will not hold so many references to the empty tuple and
the finalization code ends up trying to deallocate it (what, from my limited
understading of the code, is not supposed to happen):
run no. 0
free_list[0]->ob_refcnt before XDECREF: 2
run no. 1
free_list[0]->ob_refcnt before XDECREF: 1
Segmentation fault (core dumped)
The actual patch I'm using is much more complicated. This is just the minimal
patch able to reproduce the problem. I tried undefining Py_USING_UNICODE but
then the build doesn't succeed.
--
components: Interpreter Core
files: pythonrun.c.patch
keywords: patch
messages: 189250
nosy: Romulo A. Ceccon
priority: normal
severity: normal
status: open
title: Python crashes if Py_Initialize/Py_Finalize are called multiple times
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file30261/pythonrun.c.patch
___
Python tracker
<http://bugs.python.org/issue17978>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times
Romulo A. Ceccon added the comment: I've made some further investigation on this issue. Here's the output and the stack trace using --with-pydebug (and the attached patch applied): run no. 0 [8766 refs] free_list[0]->ob_refcnt before XDECREF: 2 run no. 1 [8844 refs] free_list[0]->ob_refcnt before XDECREF: 1 Fatal Python error: PyThreadState_Get: no current thread Aborted (core dumped) Thread 1 (Thread 0x77fed700 (LWP 32572)): #0 0x77131425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x77134b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x004086f4 in Py_FatalError ( msg=0x5a0378 "PyThreadState_Get: no current thread") at Python/pythonrun.c:1631 #3 0x0054120c in PyThreadState_Get () at Python/pystate.c:330 #4 0x0049a13b in tupledealloc (op=0x84e3a0) at Objects/tupleobject.c:218 #5 0x0047adf1 in _Py_Dealloc (op=0x84e3a0) at Objects/object.c:2262 #6 0x0049bba9 in PyTuple_Fini () at Objects/tupleobject.c:933 #7 0x0040519b in Py_Finalize () at Python/pythonrun.c:466 #8 0x004047b6 in main () A build of Python 2.7.3 using the same steps *does not* crash, although it shows the same curious behavior for free_list[0]->ob_refcnt: [8676 refs] free_list[0]->ob_refcnt before XDECREF: 2 run no. 1 [8754 refs] free_list[0]->ob_refcnt before XDECREF: 1 run no. 2 [8832 refs] free_list[0]->ob_refcnt before XDECREF: 1 I have no idea why it behaves like that, but it seems that the default configuration with Unicode enabled is covering some bug (because of the additional references held). Regarding the official way to disable Unicode, I cannot build Python using --enable-unicode=no on Ubuntu 13.04. In 2.7.4, 2.7.3, 2.7.2 and 2.6.8 ./configure aborts with: checking what type to use for unicode... configure: error: invalid value for --enable-unicode. Use either ucs2 or ucs4 (lowercase). I'm afraid I'm missing something really obvious. With 2.5.6 I'm able to get past the configure part but then it fails when building the modules. -- ___ Python tracker <http://bugs.python.org/issue17978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
