Re: Memory leaks in Octave

[John W. Eaton]

On 09/14/2017 01:32 PM, Rik wrote:
> The development branch of Octave has switched away from Valgrind (slow) to
> using a fast, lightweight memory checker (Address Sanitizer) which is built
> in to the code.  It is very easy to do as there is a configure option,
> "--enable-address-sanitizer-flags", which sets everything up.  Because this
> is new and relatively unknown, I wrote a Wiki entry for it at
> http://wiki.octave.org/Finding_Memory_Leaks.

Thanks for documenting this.

> Running '__run_test_suite__' seems to work.  But I assume there are still
> plenty of ways to cause problems because I found two within 5 minutes just
> by trying a few commands.  Maybe I was extraordinarily unlucky, but it
> would be useful if others could build with the Address Sanitizer and then
> run operate normally, i.e., use it for regular use and run your own scripts
> through it to see if it provokes any errors.

I noticed some direct leaks when just starting octave-cli and exiting 
and fixed them with this change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/a666e433aa21

Now I don't see any direct leaks when simply starting and exiting 
octave-cli, but I do see large number of indirect leaks that look 
something like

Indirect leak of 81472 byte(s) in 536 object(s) allocated from:
    #0 0x7fb36c0b6100 in operator new(unsigned long) 
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdb100)
    #1 0x7fb36ab489a0 in 
octave::symbol_table::symbol_record::symbol_record(octave::symbol_table::scope*, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> > const&, octave_value const&, unsigned int) 
/home/jwe/src/octave/libinterp/corefcn/symtab.h:625
    #2 0x7fb36b64d18b in 
octave::symbol_table::scope::insert(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const&, bool) 
/home/jwe/src/octave/libinterp/corefcn/symtab.cc:1619
    #3 0x7fb36ab44f7d in octave::base_lexer::handle_identifier() 
/home/jwe/src/octave/libinterp/parse-tree/lex.ll:3171


These appear to be caused by this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/ef85638c605a

because it prevents symbol table scopes from being cleaned up properly 
when a scope has a parent.  My goal with that patch was to avoid having 
the parent scope disappear while it was still needed by the child 
(nested or anonymous functions, for example).  It looks like I was a 
little to good at that job and prevented them from ever being deleted. 
Ooops.  I'm now looking at a way to fix this by using a different method 
for caching the parent scope.

jwe