You might want to test with the following script
import os
def report_memory(i):
pid = os.getpid()
a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
print i, ' ', a2[1],
return int(a2[1].split()[1])
for i in range(100):
your_code_here()
report_memory(i)
You should see little or no leak if everything checks out.
JDH
···
On Wed, 2005-09-07 at 16:15 +0100, Nicholas Young wrote:
>> I've attached a patch to CVS with the necessary changes below.
>> There are some issues here:
> My patch contained memory leaks which I've fixed in the
> attachment - but I'm not that experienced in c/c++ so
> there could be more I haven't noticed.
> Nick
Thanks for the suggestion John. After following it I've found another
two leaks (revised patch attached) and as a result on testing with your
suggestions get following output (at the start):
0 52604 18235
1 52608 18236
2 52608 18235
3 52608 18235
4 52608 18236
5 52608 18235
6 52608 18235
7 52608 18235
8 52612 18235
9 52612 18235
10 52612 18235
11 52612 18235
12 52612 18235
13 52612 18236
14 52612 18235
15 52616 18235
16 52616 18235
17 52616 18235
18 52616 18236
19 52616 18235
20 52616 18235
21 52616 18236
22 52616 18236
23 52616 18235
24 52616 18235
25 52616 18235
26 52616 18235
27 52616 18235
28 52616 18235
29 52616 18236
30 52616 18235
Am I correct in thinking the occasional slight increase in memory is due
to python not me?
Nick
mpl_nui.patch (9.94 KB)
···
On Wed, 2005-09-07 at 12:12 -0500, John Hunter wrote:
> My patch contained memory leaks which I've fixed in the
> attachment - but I'm not that experienced in c/c++ so
> there could be more I haven't noticed.
You should see little or no leak if everything checks out.