Changes by STINNER Victor :
Removed file: http://bugs.python.org/file17507/segfault_handler.patch
___
Python tracker
<http://bugs.python.org/issue8863>
___
___
Python-bug
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file17717/segfault_handler-2.patch
___
Python tracker
<http://bugs.python.org/issue8863>
___
___
Pytho
STINNER Victor added the comment:
> It should be tested at least on a wide build and ...
Done: it works correctly for non-BMP characters in narrow and wide builds.
Eg. in wide build with U+10 character in the path:
-
$ ./python bla.py
Fatal Python error: segmentat
STINNER Victor added the comment:
Patch version 4:
- Add segfault.c to pythoncore.vcproj
- Remove #error "nope" (I used it for debug purpose)
- Don't include on Windows
This version works on Windows.
--
Added file: http://bugs.python.org/file19210/segfault_
STINNER Victor added the comment:
> Is it always correct to decode a filename with the locale encoding
> on Unix?
Do you know something better than the locale encoding? I don't.
> Can’t each filesystem have its own encoding?
Yes, but how do you get the encoding of each files
STINNER Victor added the comment:
r85393 introduced a regression in test_runpy of Python 2.7.
--
nosy: +haypo
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
test_runpy fails also on Python 3.2.
--
___
Python tracker
<http://bugs.python.org/issue10068>
___
___
Python-bugs-list mailin
STINNER Victor added the comment:
> dmalcolm asked if it would be possible to display the
> Python backtrace on Py_FatalError()
It works :-) I fixed a bug in ceval.c (r85411) which was not directly related.
Patch version 5:
- Display the Python backtrace on Py_FatalError() (if no
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file19208/segfault_handler-3.patch
___
Python tracker
<http://bugs.python.org/issue8863>
___
___
Pytho
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file19210/segfault_handler-4.patch
___
Python tracker
<http://bugs.python.org/issue8863>
___
___
Pytho
Changes by STINNER Victor :
--
title: Segfault handler: display Python backtrace on segfault -> Display Python
backtrace on SIGSEGV, SIGFPE and fatal error
___
Python tracker
<http://bugs.python.org/iss
STINNER Victor added the comment:
I posted the patch on Rietveld for a review (as asked by Antoine):
http://codereview.appspot.com/2477041
--
___
Python tracker
<http://bugs.python.org/issue8
STINNER Victor added the comment:
Version 6:
- don't use fputc(), fputs(), fprintf() or fflush() on stderr: use write() on
file descriptor 2 (should be stderr)
- write tests: add sigsegv(), sigfpe() and fatal_error() functions to the
_testcapi module
I was too lazy to reimplement func
STINNER Victor added the comment:
TODO (maybe): Call the original signal handler to make tools like apport or
ABRT able to catch segmentation faults.
> By the way, don't you want to handle SIGILL and SIGBUS too?
Maybe. SIGILL is a very rare exception. To test it, should I send
STINNER Victor added the comment:
I commited issue9992.patch as r85430 (remove PYTHONFSENCODING) + r85435 (OSX:
decode command line arguments from utf-8).
These commits should fix this issue. Reopen the issue if you notice new
problems, or if the problem is not fixed yet. I will watch Mac OS
STINNER Victor added the comment:
Fixed by r85430 (remove PYTHONFSENCODING), see #9992.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Fixed by r85430 (remove PYTHONFSENCODING), see #9992.
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
Fixed by r85430 (remove PYTHONFSENCODING), see #9992.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
STINNER Victor added the comment:
This issue should be fixed by r85435 (OSX: decode command line arguments from
utf-8), see #9992.
I will watch for the OSX buildbots.
--
___
Python tracker
<http://bugs.python.org/issue4
Changes by STINNER Victor :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10014>
___
___
Python-bugs-list mailing list
Unsubscri
STINNER Victor added the comment:
> This issue should be fixed by r85435 ...
> I will watch for the OSX buildbots.
I don't know if it fixes the issue, but it introduces a regression. r85442
reverts it.
---
Revert r85435 (and r85440): decode command line arguments from utf-8
P
STINNER Victor added the comment:
osx_utf8_cmdline.patch: copy of r85435.
--
Added file: http://bugs.python.org/file19228/osx_utf8_cmdline.patch
___
Python tracker
<http://bugs.python.org/issue4
New submission from STINNER Victor :
It looks like the parser API (eg. PyParser_ParseFileFlagsEx,
PyParser_ASTFromFile) expects utf-8 filename: err_input() decodes the filename
from utf-8. But
Example in a non-ascii directory (/home/SHARE/SVN/py3kéŁ) and an ascii locale:
$ LANG
STINNER Victor added the comment:
test_undecodable_env() of test_subprocess fails. r85430 removes the following
code which was added by Antoine to fix this issue.
# Force surrogate-escaping of \xFF in the child process;
# otherwise it can be decoded as-is if the default locale
# is latin-1
STINNER Victor added the comment:
With r85466+r85467, the test_undecodable_env (of test_subprocess) uses C locale
to get ASCII locale encoding (for the first test, on unicode environment
variables). It should have the same effect than env['PYTHONFSENCODING'] =
'ascii
STINNER Victor added the comment:
Ok, the issue is not complelty fixed ;-)
12:55 < py-bb> build #504 of x86 debian parallel 3.x is complete: Success
[build successful] Build details are at
http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x/
STINNER Victor added the comment:
I tried... "the issue is *now* complelty fixed"
--
___
Python tracker
<http://bugs.python.org/issue9992>
___
___
STINNER Victor added the comment:
> We shouldn't need to reopen the file in the first place.
> If we already have a file handle, we can rewind it.
> Then the encoding of the file name becomes irrelevant.
Oh yes, great idea. r85476 implements this solution (use lseek(0) on
New submission from STINNER Victor :
Example:
$ ./python
Python 3.2a3+ (py3k, Oct 15 2010, 14:31:59)
>>> compile('', 'abc\uDC80', 'exec')
...
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position
3: surr
STINNER Victor added the comment:
#6543 changed code->co_filename encoding from filesystem
encoding+surrogateescape to utf-8+strict.
With my patch, compile('', '\udcc3\udca9', 'exec').co_filename gives 'é', it
doesn't depend on the file
STINNER Victor added the comment:
See also #9713.
--
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
See also issue #10114.
--
___
Python tracker
<http://bugs.python.org/issue9713>
___
___
Python-bugs-list mailing list
Unsub
STINNER Victor added the comment:
> All filenames should use the filesystem encoding in Python.
Here is a new patch [code_encoding.patch] implementing this idea:
- Use filesystem encoding (and surrogateescape) to encode/decode paths in
compile() and the parser, instead of utf-8 in str
STINNER Victor added the comment:
> I do not see what filesystem encodings, or any other encoding
> to bytes should really have to do with the [code.co_filename].
co_filename attribute is used to display the traceback: Python opens the
related file, read the source code line and disp
STINNER Victor added the comment:
Remove [compile_surrogates.patch] because it creates filenames unencode to the
filesystem encoding. Eg. compile('', '\udcc3\udca9', 'exec').co_filename gives
'é' e
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file19243/compile_surrogates.patch
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Pytho
STINNER Victor added the comment:
> Here is a new patch [code_encoding.patch] implementing this idea:
> - Use filesystem encoding (and surrogateescape) to encode/decode
> paths in compile() and the parser, instead of utf-8 in strict mode
> (...)
> The patch restores the situati
STINNER Victor added the comment:
Oh, I just realized that Python 3.1.2 (last Python 3.1 release) was released
the 21st March, whereas r82063 (commit for #6543) was made the 17st June. So
the encoding change was not released yet.
--
___
Python
STINNER Victor added the comment:
Commited to 3.2 (r85569+r85570). I wait for the buildbot before porting the
patch to 3.1 and close the issue. There is already a regression on Gentoo
buildbot with ascii locale encoding, test_doctest test_zipimport_support:
http://www.python.org/dev/buildbot
New submission from STINNER Victor :
In #10114, I changed parser filename encoding from utf-8/strict to the
filesystem encoding/surrogateescape. With C locale, the filesystem encoding is
ASCII and test_doctest fails because it uses an unencoable filename
(foo-b...@baz.py).
A solution is to
STINNER Victor added the comment:
I created #10123 for the test_doctest regression.
--
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Python-bug
STINNER Victor added the comment:
Failures occurred on:
http://www.python.org/dev/buildbot/builders/AMD64%20Gentoo%20Wide%203.x
http://www.python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%203.x
test_zipimport_support does also fail, but it is linked to test_doctest
failures
STINNER Victor added the comment:
Fixed by r85578.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10123>
___
__
STINNER Victor added the comment:
Status of this issue, 5 months later: most tests pass except test_gc test_gdb
test_runpy test_sys test_wsgiref test_zipimport. Said differently, 95% of the
task (or more?) is done. It's possible to run Python installed in a non-ascii
directory wit
STINNER Victor added the comment:
Updated list of failing test with py3k and a non-ascii path:
* Linux, LANG=C: test_gc test_gdb test_runpy test_zipimport
* Windows: test_email test_httpservers test_zipimport
Possible reasons:
* test_httpservers (CGIHTTPServerTestCase.setUp): test should be
STINNER Victor added the comment:
r85655 fixed test_gdb failure.
test_runpy failure looks to be linked to test_zipimport problems.
--
___
Python tracker
<http://bugs.python.org/issue8
STINNER Victor added the comment:
r85659 + r85662 + r85663 fixed test_httpservers.
--
___
Python tracker
<http://bugs.python.org/issue8611>
___
___
Python-bug
STINNER Victor added the comment:
Good news: this issue is now fixed in py3k (Python 3.2). I cannot give a commit
number, because there are too much commits related to this problem (see #8611
and #9425), but it works ;-)
--
resolution: -> fixed
status: open ->
New submission from STINNER Victor :
See attached file for the full output. One example:
== CPython 3.2a3+ (py3k:85660, Oct 17 2010, 21:57:48) [MSC v.1500 32 bit
(Intel)]
== Windows-XP-5.1.2600-SP3 little-endian
==
FAIL
STINNER Victor added the comment:
> Victor, can you paste or attach the error for email?
It doesn't look to be related to the path name (same failure with "py3ké" or
"py3k" directory name), so I opened #10134.
--
_
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue5111>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
Starting at r85691, the full test suite of Python 3.2 pass with ASCII,
ISO-8859-1 and UTF-8 locale encodings in a non-ascii directory. The work on
this issue is done.
--
resolution: -> fixed
status: open ->
STINNER Victor added the comment:
Starting at r85691, the full test suite of Python 3.2 pass with ASCII,
ISO-8859-1 and UTF-8 locale encodings in a non-ascii directory. The work on
this issue is done.
--
resolution: -> fixed
status: open ->
STINNER Victor added the comment:
Buildbots are green again (#10123 is closed). I ported the fix to Python 3.1
(r85716). Close this issue.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
I'm not sure that the patch is still needed on Python 3.2.
--
___
Python tracker
<http://bugs.python.org/issue6011>
___
___
STINNER Victor added the comment:
See issue #10114: fixed in Python 3.1 (r85716) and in Python 3.2
(r85569+r85570).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
STINNER Victor added the comment:
I tested the example with Python 3.2 (r85691) and the issue looks to be fixed.
Can someone else confirm that?
I decompressed the ZIP archive, moved into the directory containing a.py and
b.py, and called \path\to\python.exe a.py: it works
STINNER Victor added the comment:
See also #3080 for the full unicode support in the import machinery.
--
___
Python tracker
<http://bugs.python.org/issue8
STINNER Victor added the comment:
With #8611 and #9425, I patched a lot of functions and modules, including the
NullImporter and zipimport, but not the core of the import machinery.
In my import_unicode SVN branch, I patched the import machinery to manipulate
unicode strings, instead of
STINNER Victor added the comment:
FYI, I finished my work on non-ascii filenames in Python 3.2 (#8611, #9425):
Python 3.2 now suports any filename with any locale (filesystem) encoding.
--
___
Python tracker
<http://bugs.python.org/issue1552
STINNER Victor added the comment:
Patch version 7:
- don't use snprintf() because it is not signal safe
- catch also SIGBUS and SIGILL if available
- Py_FatalError() uses fileno(stderr) instead of directly 2
- Factorize code in segfault.c and test_segfault.py
--
Added file:
STINNER Victor added the comment:
Patch version 8:
- fix compiler warning on Windows
- skip test_sigfpe() on Windows: it looks like the signal handler is not
executed, the program exits directly
- fix tests for Windows end of line (\r\n vs \n)
--
Added file: http://bugs.python.org
STINNER Victor added the comment:
> One other concern: many OSes (e.g. Linux distributions) implement
> some kind of system-wide crash-catching utility; ...
Even if it would be possible to call the original signal handler, I think that
it would be better to just disable this featur
STINNER Victor added the comment:
initfsencoding() now raises a fatal error on get_codeset() error. Use a
encoding different than the locale encoding on get_codeset() only leads to
mojibake and encoding issues, it's not a good idea. Close this issue as invalid.
--
resol
STINNER Victor added the comment:
> One solution would be to duplicate the UTF-8 decoder for OSX,
> incorporating surrogate escape. This should be much shorter
> than the full UTF-8 codec, and perhaps at least utf8_code_length
> could be shared.
Good idea, implemented in the at
STINNER Victor added the comment:
_Py_DecodeUTF8_surrogateescape() is a simplified version of
PyUnicode_DecodeUTF8Stateful():
- no "consumed" argument
- only support surrogateescape error handler
- no optimization
- don't resize the buffer at exit
Hum, resize the buffer
STINNER Victor added the comment:
I commited my patch to Python 3.2 (r85765), with a specific test in
test_cmd_line. Reopen the issue if the bug is not fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
New submission from STINNER Victor :
On a failure, unittest does its best to display values. But sometimes, the
output doesn't help me. Example:
FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
--
Traceback (most r
Changes by STINNER Victor :
--
components: +Unicode
___
Python tracker
<http://bugs.python.org/issue7828>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I just closed #4388 with r85765 (Python 3.2): always use UTF-8 to decode the
command line arguments on Mac OS X, not the locale encoding.
I suppose that it does fix this issue. Can someone check that
STINNER Victor added the comment:
Since r85765 (issue #4388), always use UTF-8 to decode the command line
arguments on Mac OS X, not the locale encoding. Which means that the
pseudo-code becomes:
if os.name != 'nt':
if sys.platform == 'darwin':
encoding
STINNER Victor added the comment:
> $ LC_ALL=C ./python
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> SystemError: NULL result without error in PyObject_Call
> Abandon
What is your Python version? I fixed Python 3.2, but I don't plan to fix Pyt
STINNER Victor added the comment:
FYI, you should use ascii() instead of a.encode(\"utf8\") to dump arguments.
It's easier to check '\u2603' than b'\xe2\x98\x83' for me :-)
So the bug is fixed in Python 3.2, great! I was thinking that we need a test
for
STINNER Victor added the comment:
> I’m trying to build py3k on posix in a subdir called
> sep-build-dir-éric, with locale set to C.
Ah yes, this particular use case doesn't work: r85800 should fix it. Please
retry.
--
___
Python tra
STINNER Victor added the comment:
Commited to Python 3.1 (r85802).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
> Same errors.
Please describe exactly how you reproduced the error (write each command).
r85805 fixes another bug related to this problem. Is it a better fix than
distutils_makefile_encoding.patch: use surrogateescape error handler to decode
the Makef
STINNER Victor added the comment:
Prototype (in Python) of argvb.py. Try it with: ./python -i argvb.py.
It's not possible to create sys.argvb in Python in a module loaded by
Py_Initialize(), because sys.argv is created after Py_Initialize().
--
Added file: http://bugs.pytho
STINNER Victor added the comment:
Fixed by r85827.
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
STINNER Victor added the comment:
Closed with r85829: patch test_pep277 instead of unittest.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Don't you know http://www.nongnu.org/failmalloc/?
--
___
Python tracker
<http://bugs.python.org/issue10195>
___
___
Pytho
STINNER Victor added the comment:
> ... every call to PyRun_InteractiveOneFlags immediately returns
>(the PyUnicode_FromString("stdin") in within PySys_GetObject() fails
> to allocate memory); this leads to a tight loop sending the total
> refcount to stderr:
I thin
New submission from STINNER Victor :
PyUnicode_EncodeFSDefault() and os.fsencode() should decompose the filename
(NFD) before encoding it to utf-8.
PyUnicode_DecodeFSDefault(AndSize)() and os.fsdecode() should precompose the
filename (NFC) after decoding it from utf-8.
Qt library does this
STINNER Victor added the comment:
I opened the issue #10209: "Mac OS X: Decompose filenames on encode, and
precompose filenames on decode".
--
___
Python tracker
<http://bugs.python.
STINNER Victor added the comment:
Patch for os.fsencode/fsdecode importing unicodedata in the function (instead
of a global import). unicodedata module is not builtin and is dynamically
loaded. We should maybe ignore ImportError if the module is not available? With
a warning?
For
New submission from STINNER Victor :
Using -b command line option, os.get_exec_path() always produce a warning.
Example:
$ ./python -b
>>> import os: os.get_exec_path({'PATH': ''})
.../Lib/os.py:395: BytesWarning: Comparison between bytes and string
path_listb
STINNER Victor added the comment:
Prototype to test nonblocking file objet:
- add getblocking() and setblocking() methods to _io._FileIO and all _pyio
classes
- fileio_setblocking() is implemented using fcntl(fd, F_SETFL, flags |
O_NONBLOCK) (POSIX only?)
- BufferedReader.read() uses read1
Changes by STINNER Victor :
Added file: http://bugs.python.org/file19385/test_process.py
___
Python tracker
<http://bugs.python.org/issue949667>
___
___
Python-bugs-list m
STINNER Victor added the comment:
> I'd like to see this patch reverted.
I created a specific branch to test the patch (I also patched
PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()):
issue10209. test_pep277 now pass in this branch!
> encoding with NFD sh
STINNER Victor added the comment:
Some pointers.
"MacFUSE"
http://code.google.com/p/macfuse/issues/detail?id=139#c2
"FILENAME_ENCODING_PROPOSAL" (MacFUSE)
http://code.google.com/p/macfuse/wiki/FILENAME_ENCODING_PROPOSAL
"Converting to Precomposed Unicode"
http
STINNER Victor added the comment:
> My question is rather why it failed in the first place,
> when issue8207 had supposedly fixed it.
r79426 (of #8207) only disabled some tests.
The problem with test_normalize() and test_listdir() of test_pep277 is maybe
that these tests are irrevel
STINNER Victor added the comment:
> The problem with test_normalize() and test_listdir() of test_pep277
> is maybe that these tests are irrevelant on Mac OS X?
I tried a different approach (different than my patch and the svn branch):
- r85897 disables the filenames that are norm
STINNER Victor added the comment:
> - r85897 disables the filenames that are normalized differently by Python and
> by darwin
> - r85899 disables test_normalize and test_listdir tests
It looks like r85897 is enough to fix test_pep277 on "x86 Tiger 3.x" buildbot.
But r85
STINNER Victor added the comment:
I now agree with Martin: "Mac OS X: Decompose filenames on encode, and
precompose filenames on decode" was a bad idea, fix the test is the right
solution.
test_pep277 now pass on "x86 Tiger 3.x" buildbot, and so I can close this is
STINNER Victor added the comment:
> I opened the issue #10209: "Mac OS X: Decompose filenames on encode,
> and precompose filenames on decode".
It was a bad idea. I fixed test_pep277 instead with:
- r85897 disables the filenames that are normalized differently by Pytho
Changes by STINNER Victor :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10209>
___
___
Python-bugs-list
STINNER Victor added the comment:
Fixed by r85902.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10210>
___
__
New submission from STINNER Victor :
test_tarfile in only failing on one 3.x buildbot: AMD64 debian parallel 3.x.
The problem is related to the mtime field and os.utime():
http://www.python.org/dev/buildbot/builders/AMD64 debian parallel
3.x/builds/508/steps/test/logs/stdio
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10184>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I reproduced the problem with the following commands:
cd py3k
export LANG=C
export LC_ALL=C
make distclean
./configure --with-pydebug --prefix=/home/haypo/tmp/py3ké
make
It looks like the problem is that srcdir environment variable of Makefile.pre
is ".
STINNER Victor added the comment:
I would also be nice to have a "monotonic" clock in Python. See monotonic.py
for an example. But I don't know if it solves the same problem than
time.wallclock() or not. I need a monotonic clock for a server on which NTP is
sometimes called t
2401 - 2500 of 35284 matches
Mail list logo
