[ python-Bugs-868864 ] 8-bit string literal with iso8859 coding => crash

SourceForge.net noreply at sourceforge.net
Thu Aug 25 09:30:53 CEST 2005


Bugs item #868864, was opened at 2004-01-01 18:30
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Martin v. Löwis (loewis)
Summary: 8-bit string literal with iso8859 coding => crash

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-25 09:30

Message:
Logged In: YES 
user_id=21627

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

----------------------------------------------------------------------

Comment By: Mike Rozhnov (rozhnov)
Date: 2004-04-22 14:00

Message:
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).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-02-16 15:44

Message:
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.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2004-01-02 09:58

Message:
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".

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-01-01 20:53

Message:
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?

----------------------------------------------------------------------

Comment By: L. Peter Deutsch (lpd)
Date: 2004-01-01 18:32

Message:
Logged In: YES 
user_id=8861

'make test' ran with no problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470


More information about the Python-bugs-list mailing list