Neil Schemenauer writes:

Guilty as charged. Can you explain how the current code is leaking memory? I can see one problem with deallocating size=0 tuples. Are there any more leaks?

Actually, I think I may have spoken too hastily - it's late and I'm tired and I should be sleeping rather than staring at the screen (like I've been doing since 8:30 this morning) - I jumped to conclusions - I'm not really sure that it was your patch that caused the leak; all I can say with 100% certainty is that if you run "test_extcall" in a loop, memory usage goes through the ceiling.... It's not just the cyclic garbage caused by the "saboteur" function because even with this commented out, the memory leak persists. I'm actually trying to track down a different memory leak, something which is currently causing trouble in one of our production servers (more about this some other time) and just as a sanity check I ran my little "leaktest.py" script over all the test_*.py modules in the distribution, and found that test_extcall triggers leaks... having analyzed and fixed this once before (see the CVS logs for tupleobject.c), I jumped to conclusions about the reason for its return. I'll take a more clear-headed and careful look tomorrow and post something (hopefully) a little more conclusive. It may have been some other change that caused this memory leak to re-appear. If you feel inclined to investigate, just do "reload(test.test_extcall)" in a loop and watch the memory usage with ps or top or what-have-you... -C

Neil Schemenauer writes:

Guilty as charged. Can you explain how the current code is leaking memory? I can see one problem with deallocating size=0 tuples. Are there any more leaks?

Actually, I think I may have spoken too hastily - it's late and I'm tired and I should be sleeping rather than staring at the screen (like I've been doing since 8:30 this morning) - I jumped to conclusions - I'm not really sure that it was your patch that caused the leak; all I can say with 100% certainty is that if you run "test_extcall" in a loop, memory usage goes through the ceiling.... It's not just the cyclic garbage caused by the "saboteur" function because even with this commented out, the memory leak persists. I'm actually trying to track down a different memory leak, something which is currently causing trouble in one of our production servers (more about this some other time) and just as a sanity check I ran my little "leaktest.py" script over all the test_*.py modules in the distribution, and found that test_extcall triggers leaks... having analyzed and fixed this once before (see the CVS logs for tupleobject.c), I jumped to conclusions about the reason for its return. I'll take a more clear-headed and careful look tomorrow and post something (hopefully) a little more conclusive. It may have been some other change that caused this memory leak to re-appear. If you feel inclined to investigate, just do "reload(test.test_extcall)" in a loop and watch the memory usage with ps or top or what-have-you... -C