Re: Memory leaks from octave --eval 'quit'

[Ben Abbott]

> On Jul 3, 2016, at 9:43 AM, Robert Jenssen <address@hidden> wrote:
> 
> Hi,
> 
> When I run valgrind or address-sanitizer on octave --eval 'quit' I get
> many messages about memory leaks. These leaks may or not be a problem.
> They do make it harder to see real bugs and probably discourage the use
> of valgrind and address-sanitizer. I've had a lot of use of octave over
> the years and I suggested the use of address-sanitizer so perhaps this
> is where I can make a contribution.
> 
> 
> There are two bug reports about this:
> 
>  bug #35502, Memory leak in load-path.cc
>  bug #44420, Memory leaks in 4.0 RC
> 
> and this thread on the mailing list:
> 
> Re: singleton cleanup issues (was: Re: Fwd: octave segfaults
> during        exit
> https://lists.gnu.org/archive/html/octave-maintainers/2012-01/msg00039.html
> 
> 
> 
> There are two related problems:
> 
> 1. examples/code/make_int.cc seg. faults. I reproduced this on the
> current sources by un-commenting line 882 in
> libinterp/corefcn/toplev.cc: 
> 
> -      // OCTAVE_SAFE_CALL (singleton_cleanup_list::cleanup, ());
> +      OCTAVE_SAFE_CALL (singleton_cleanup_list::cleanup, ());
> 
> and running:
> 
> # /usr/local/dbg-octave/bin/mkoctfile ../octave/examples/code/make_int.cc
> ...
> # gdb /usr/local/dbg-octave/bin/octave-cli
> ...
> (gdb) run -f --eval 'myint = make_int(10)'
> ...
> installing integer type at type-id = 55
> myint =
> 
> 10
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff6f03020 in octave_refcount<int>::operator--
> (this=0x7fffe491d238) at ../octave/liboctave/util/oct-refcount.h:73
> 73        return OCTREFCOUNT_ATOMIC_DECREMENT (&count);
> ...
> (gdb) bt
> #0  0x00007ffff6f03020 in octave_refcount<int>::operator-- (
>    this=0x7fffe491d238) at ../octave/liboctave/util/oct-refcount.h:73
> #1  0x00007ffff6f007e6 in octave_value::~octave_value (this=0x67a6a8, 
>    __in_chrg=<optimized out>)
> at ../octave/libinterp/octave-value/ov.h:323 #2  0x00007ffff6f04e2a in
> Array<octave_value>::ArrayRep::~ArrayRep ( this=0x67bd60,
> __in_chrg=<optimized out>) at ../octave/liboctave/array/Array.h:91
> #3  0x00007ffff6f03691 in Array<octave_value>::~Array (this=0x6633c0, 
>    __in_chrg=<optimized out>) at ../octave/liboctave/array/Array.h:217
> #4  0x00007ffff73543e4 in octave_value_typeinfo::~octave_value_typeinfo
> ( this=0x663390, __in_chrg=<optimized out>)
>    at ../octave/libinterp/octave-value/ov-typeinfo.h:213
> #5  0x00007ffff7354417 in octave_value_typeinfo::cleanup_instance ()
>    at ../octave/libinterp/octave-value/ov-typeinfo.h:221
> #6  0x00007ffff6484856 in
> singleton_cleanup_list::~singleton_cleanup_list ( this=0x618b90,
> __in_chrg=<optimized out>)
> at ../octave/liboctave/util/singleton-cleanup.cc:38 #7
> 0x00007ffff7840ad0 in singleton_cleanup_list::cleanup ()
> at ../octave/liboctave/util/singleton-cleanup.h:28 #8
> 0x00007ffff783aa40 in do_octave_atexit ()
> at ../octave/libinterp/corefcn/toplev.cc:886 #9  0x00007ffff783c4f9 in
> clean_up_and_exit (status=0, safe_to_return=false)
> at ../octave/libinterp/corefcn/toplev.cc:894 #10 0x00007ffff6eff071 in
> octave_execute_interpreter () at ../octave/libinterp/octave.cc:928
> #11 0x00000000004016c9 in main (argc=4, argv=0x7fffffffe1e8)
>    at ../octave/src/main-cli.cc:92
> (gdb) 
> 
> The solution for the seg. fault was changeset 14156:d5d3037cbc11 "don't
> call singleton_cleanup_list::cleanup on exit" which disabled all calls
> to functions that had been added to singleton_cleanup_list. 
> 
> I propose:
> 
> a. Keep the call to singleton_cleanup_list in toplev.cc and instead
> avoid this seg. fault by modifying ov-typeinfo.h line 221:
> 
> -  static void cleanup_instance (void) { delete instance; instance =
>  0; }
> +  static void cleanup_instance (void) {
> +    // delete instance; instance = 0;
> +  }
> 
> b. Add a bug report for the seg. fault in examples/code/make_int.cc.
> 
> 
> Making these two changes reduces the number of loss records reported by
> valgrind from 3641 to 1818 on my debug builds.
> 
> 
> 2. There are a lot of memory leaks from ov-classdef.h and
> ov-classdef.cc. The classdef code contains two sorts of singletons:
> 
>  - the cdef_manager singleton is allocated on the heap
> 
>  - a "quintuple singleton" in cdef_package and cdef_class allocated at
>    startup:
> 
>  static cdef_class _meta_class;
>  static cdef_class _meta_property;
>  static cdef_class _meta_method;
>  static cdef_class _meta_package;
>  static cdef_package _meta;
> 
> The cdef_manager singleton registers a cleanup function on
> singleton_cleanup_list. Valgrind shows that the cdef_class and
> cdef_package singletons leave a lot of heap memory allocated on exit.
> I propose adding an cleanup_instance() function to the cdef_class and
> cdef_package code to try to clear out the heap allocations when octave
> shuts down.
> 
> There are memory leaks in the parser.
> 
> Feedback?

Presently, I’m seeing problems when building the stable branch.

 GEN      plot3.pdf
ASAN:DEADLYSIGNAL
=================================================================
==66572==ERROR: AddressSanitizer: SEGV on unknown address 0x602017800062 (pc 
0x7fff9133fa9b bp 0x7fff574b37b0 sp 0x7fff574b3798 T0)

In the past, I’ve also seen these problems come and go when building the 
default branch.

I’d like to encourage your proposal and am happy to test code on Mac OS X.

Ben