On Jul 28, 2009, at 5:20 AM, Simon King wrote: > > Hi! > > In the attempt to hunt down a memleak in my cohomology package, I > found something that I can't understand. Can you perhaps explain what > happens? > > Put the following code into a file int2Z.pyx: > > def test(N): > cdef int i > for i from 0 <= i <= N: > a += 1 # just in order to avoid that the loop is empty > > Now, after installing the valgrind-spkg and doing sage -ba, I did the > following on an Intel Core Duo with GNU Linux: > >> sage -valgrind > ---------------------------------------------------------------------- > | Sage Version 4.1, Release Date: 2009-07-09 | > | Type notebook() for the GUI, and license() for information. | > ---------------------------------------------------------------------- > /home/king/SAGE/sage-4.1/local/bin/sage-ipython > Log file is /home/king/.sage/valgrind/sage-memcheck.%p > Using default flags: > --leak-resolution=high --log-file=/home/king/.sage/valgrind/sage- > memcheck.%p --leak-check=full --num-callers=25 --suppressions=/home/ > king/SAGE/sage-4.1/local/lib/valgrind/sage.supp > Python 2.6.2 (r262:71600, Jul 27 2009, 13:41:09) > [GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on > linux2 > Type "help", "copyright", "credits" or "license" for more information. > sage: attach int2Z.pyx > Compiling /home/king/tests/int2Z.pyx... > sage: test(100000) > sage: quit > Exiting SAGE (CPU time 0m1.79s, Wall time 0m9.32s). > > I put the valgrind log at > http://sage.math.washington.edu/home/SimonKing/logs/ > memcheck.int2Integer > > This simple code results in: > ==26929== LEAK SUMMARY: > ==26929== definitely lost: 8 bytes in 1 blocks. > ==26929== possibly lost: 436,049 bytes in 1,043 blocks. > ==26929== still reachable: 49,247,285 bytes in 30,191 blocks. > > If I interprete the valgrind log correctly, the problem is the > conversion of a python integer to an Integer. Therefore I tested > various modifications of the code, e.g., > > def test(int N): > cdef int i > cdef int a=0 > for i from 0 <= i <= N: > a += 1 # just in order to avoid that the loop is empty > > But this didn't help. > > Questions: > > - Note that valgrind says "Log file is /home/king/.sage/valgrind/ > sage- > memcheck.%p". It does *not* say what number "%p" refers to. Bug?
Inadequate documentation. Probably the process id. > - The code is very simple and probably ubiquitous in the sage > library. Hence I can hardly believe that there is a memory leak on > such a basic level without being noticed by many people. Did I > misinterpret the valgrind log? I would start up Sage without importing your code to get a baseline. That's very surprising--I don't know much about valgrind, but it only shows where the memory in question was allocated, not where it was leaked. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
