octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memory leaks (was: Re: Patch tracker/Patches submitted 1 week window)


From: John W. Eaton
Subject: memory leaks (was: Re: Patch tracker/Patches submitted 1 week window)
Date: Thu, 17 Oct 2013 15:12:08 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 10/17/2013 01:35 PM, Rik wrote:

In fact, jwe and I have jumped out ahead and
plugged all the memory leaks found from running the full test suite under
valgrind.

With the singleton cleanup uncommented in do_octave_atexit, I see this
result after running the full test suite with "valgrind --tool=memcheck
--leak-check=full":

  ==30134== LEAK SUMMARY:
  ==30134==    definitely lost: 0 bytes in 0 blocks
  ==30134==    indirectly lost: 0 bytes in 0 blocks
  ==30134==      possibly lost: 5,636 bytes in 87 blocks
  ==30134==    still reachable: 282,190 bytes in 4,351 blocks
  ==30134==         suppressed: 0 bytes in 0 blocks
==30134== Reachable blocks (those to which a pointer was found) are not shown.
  ==30134== To see them, rerun with: --leak-check=full --show-reachable=yes

That's a big improvement over where we were about two years ago:


https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-December/025909.html

Unfortunately, I don't think it is possible for us to actually enable
the singleton cleanup yet (see the comment in toplev.cc).  But we may
eventually be able to do that or something similar.  My hope is
that we can eliminate the need for the singleton cleanup code by
creating an "octave_interpreter" class that will contain all the
current singleton objects as ordinary data members so that the
octave_interpreter constructor and destructor will take care of
acquiring and releasing all the necessary resources.  Doing that will
require some significant restructuring.  Octave 5.0, anyone?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]