Memory leaks from octave --eval 'quit'

[Robert Jenssen]

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?