Environment:
Python 2.3.3, built from unmodified out-of-the-tarball
sources
(./configure, make, make install)
Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs)

Symptom:
python out.py
Segmentation fault

Logged In: YES 
user_id=8861

'make test' ran with no problems.

Logged In: YES 
user_id=33168

Looks like there may be an off-by-1 error in the
implementation of PEP263.  Attached is a valgrind report. 
Martin, do you have any ideas?

Logged In: YES 
user_id=92222

Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 32 bit
(Intel)] on win32
Windows 2kSP4
Effect is the same - Python crashes with "memory can not be
written".

Logged In: YES 
user_id=21627

It's much worse than off-by-one. fp_readl reads size-1 bytes
from the input stream, reencodes them as UTF-8, and tries to
fit them into size bytes. In the example, it tries to put
8860 bytes into space for 8192 bytes.

I believe fp_readl should extend the buffer, using code
similar to tok_nextc.

Alternatively, fp_readl could, conservatively, request only
size/4 bytes from the underlying input stream, knowing that,
for most encodings, converting to UTF-8 will increase the
size at worst by a factor of 4. The assertion that the
result still fits should then become a FatalError.

Logged In: YES 
user_id=1026824

Is it possible to fix this bug before Python 2.4 release?

For now choices when using 8-bit literals are:
 - always receive warning about PEP-263
 - possible crash after editing any source module with 8-bit
literals in any time

Sorry. I can't fix this bug myself (don't have and use
Visual C).

Logged In: YES 
user_id=21627

This bug is now fixed in the CVS, for 2.5 and 2.4.2.