[Python-bugs-list] [ python-Bugs-565993 ] string.replace() can corrupt heap

noreply@sourceforge.net noreply@sourceforge.net
Mon, 10 Jun 2002 12:32:35 -0700


Bugs item #565993, was opened at 2002-06-07 17:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 3
Submitted By: Mike Romberg (romberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.replace() can corrupt heap

Initial Comment:
  I've been using a tool called mpatrol
(http://www.cbmamiga.demon.co.uk/mpatrol/) to cleanup an
embeded python application we have and ran into this
bug.  It seems to affect a stock python as well.  Under
certain
conditions it appears that one can get python to acess
freed
memory by calling string.replace or the string replace
method.

  Here is an example python command which reproduces
the problem:

python -c "a = 'a\000'; a.replace('\000', '')"

  The mpatrol library dumps the following logfile:

(see attachment)




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

Comment By: Tim Peters (tim_one)
Date: 2002-06-07 21:57

Message:
Logged In: YES 
user_id=31435

When somebody gets a report from one of these tools, 
there are 3 possibilities:

1. It's a bug in Python.
2. It's a bug in the tool.
3. It's a bug in the platform C library, compiler, or OS.

Historical fact is that #2 is the most frequent outcome, and 
these usually burn lots of time to pin the blame, so you're 
going to have to do more work if you want this taken 
seriously.

I stepped through your test case under a debugger using 
2.2.1, and saw nothing wrong.  There's a memcpy with a 
length of 0 where your tool reports "a problem", but that's 
not an error, and the addresses passed at that point are to 
legitimate memory regardless.  It's possible that your 
platform C library optimizes memcpy under the covers by 
reading up more memory than was requested, but platform 
libraries are outside of Python's control, and platform 
library authors generally "cheat" in safe ways.

At the very least, can you get into a debugger and find 
some reason to believe there's a real problem here better 
than "some program said so"?  If not, I'm inclined to close 
this as a 3rd-party bug without burning more time on it.

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

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