On Oct 25, 12:46 pm, Simon King <[EMAIL PROTECTED]> wrote:
> Dear Michael and all others,

Hi Simon,

> I tried 3 approaches to trac my problem down. Summary: It seems that
> my extension class is deallocated (__dealloc__ is called) but not
> deleted (__del__ is not called), see approach 3 below.
>
> 1.
> On Oct 24, 6:03 pm, mabshoff <[EMAIL PROTECTED]
>
> dortmund.de> wrote:
>
> > You need to rebuild Python after exporting SAGE_VALGRIND=yes -
> > otherwise pymalloc is used and as is the valgrind log is useless in
> > some regards.
>
> Thanks.
> I did rebuild sage 3.1.4 with SAGE_VALGRIND=yes, installed the
> optional valgrind spkg, and tried again.
>
> After computing "F=F5(); G=F(I)" I had
> sage: get_memory_usage()
> 1125.95703125
>
> and after repeating the same computation 10 more times in a loop, it
> was
> sage: get_memory_usage()
> 1197.0703125
>
> This time, valgrind found a tiny bit of unreachable memory, 
> seehttp://sage.math.washington.edu/home/SimonKing/f5/sage-memcheck.25789
> ==25789== LEAK SUMMARY:
> ==25789==    definitely lost: 697 bytes in 17 blocks.
> ==25789==      possibly lost: 399,844 bytes in 1,033 blocks.
> ==25789==    still reachable: 38,600,299 bytes in 332,837 blocks.
> ==25789==         suppressed: 337,860 bytes in 5,348 blocks.
>
> However, this still does not explain the loss of 71 MB reported by
> get_memory_usage

This is pretty much as expected, but now that pymalloc is no longer
used the log is likely much more readable, since a lot of false
positives are gone.

> 2.
>
> > Debugging these is hard and
> > valgrind will not help much in that case. Much more useful could be
> > Guppy.
>
> I installed guppy. hpy told me that after the first round of my
> computation I had (only indicating those items that increased)
> Index  Count   %     Size   % Cumulative  % Kind (class / dict of
> class)
>     1     42  15     4264  16     13480  50 tuple
>     4     19   7     2280   8     21416  79 unicode
>     5      3   1     1608   6     23024  85 dict (no owner)
>     9     11   4      560   2     26312  97 str
>
> But after 10 more runs I got
>      1     55  15     7424  20     16640  45 unicode
>      2      4   1     4960  13     21600  59 dict (no owner)
>      3     44  12     4408  12     26008  71 tuple
>      7     46  13     1104   3     34208  93 int
>      8     14   4      704   2     34912  95 str
>
> Unfortunately I did not find a guppy tutorial. In particular, I don't
> know how to find out where the increased size of the dicts and
> unicodes comes from.

Yep, that is somewhat of a black art. I am planning to do a talk at SD
11 about Guppy since my project there involves debugging a similar
problem, but I have nothing obvious to contribute here. Is the latest
version of f5.pyx in the wiki so I can play around with it?

> 3.
> Is the following method a correct way of testing whether instances of
> my extension classes are deleted at all?
>   - In the init method of my class "DecoratedPolynomial", I increased
> two globally defined counters by one.
>   - I provided a custom __del__ method, that did nothing but to reduce
> the first counter by one.
>   - I provided a custom __dealloc__ method, that simply reduced the
> second counter by one.
>
> Result:
> The init method was called 429 times (in 11 runs of the computation
> and deleting everything in the end), and so was the __dealloc__
> method.
> But the __del__ method was not called *at all*!

Mhh, some Python god need to comment here. But once any python element
goes out of scope and the reference count is zero it gets deallocated.
You could sprinkle your code with manual reference count checks and
see if any one of them is going up and is never decremented when it
should. But that is also a black art IMHO :)

> So, could this be at the core of the problem? I thought that a
> __dealloc__ method is called only after the __del__ method has done,
> or am I mistaken?
> To avoid misunderstanding: In my original code I did not provide
> custom __del__ or __dealloc__, but expected Cython to do the job.
>
> Cheers
>         Simon

Cheers,

Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to