On 09/18/2017 09:00 AM, address@hidden wrote:
> Subject:
> Re: Memory leaks in Octave
> From:
> "John W. Eaton" <address@hidden>
> Date:
> 09/18/2017 07:45 AM
> To:
> address@hidden
> CC:
> address@hidden
> List-Post:
> <mailto:address@hidden>
> Content-Transfer-Encoding:
> 7bit
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <address@hidden>
> In-Reply-To:
> <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type:
> text/plain; charset=utf-8; format=flowed
> Message:
> 3
>
> 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
I didn't see this because I usually run with ASAN_OPTIONS set to
"leak_check_at_exit=0:verbose=1". But, clearly this is a good
reason to occasionally run the full Address Sanitizer which would
detect slow memory leaks like this.
--Rik
|