While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!

Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

Logged In: YES 
user_id=31435

I'm afraid we're both hallucinating, so reduced the 
priority again.  The  "--i >= 0" is executed before the 
loop begins, so the first value of i is in fact o->ob_size-
1.

So the question shifts to what Purify thinks is wrong.

Logged In: YES 
user_id=132786

Upon futher investigation this may be a bug in the optimizer
from the SGI 7.3.1.2m compilers.  I'm still checking....

Logged In: YES 
user_id=132786

I just ran the code thru insure++ and you may want to look
at some of the errors...
Some of the 0 size rallocs/mallocs may be causing problems. 
The **FREE_DANGLING** may also be serious.

Logged In: YES 
user_id=31435

Changed "Summary" line to better reflect the current state, 
and reassigned to Barry.

Logged In: YES 
user_id=12800

I'm going to close this bug because Insure/Purify reports
tend to go out of date fairly quickly, especially when the C
code undergoes as radical changes as descr-branch.  We've
got Insure and I try to routinely run it on the codebase to
find memory problems.

What is much more helpful than Purify/Insure output is
reproducible code samples that illustrate a memory problem
or leak.  The smaller and more self contained the sample is
the better (i.e. it's better to highlight one leak than
100's).  Feel free to assign any such future leak/memory
bugs to me.