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)

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.

Logged In: YES 
user_id=61373

  After looking at this some more, I now think you are
correct.  This is a false positive reported by the tool.
Sorry for wasting your time with this.

Logged In: YES 
user_id=31435

Thanks for the followup, Mike!  Closing as 3rd Party.