[Octave-bug-tracker] [bug #35502] Memory leak in load-path.cc

[Rik]

URL:
  <http://savannah.gnu.org/bugs/?35502>

                 Summary: Memory leak in load-path.cc
                 Project: GNU Octave
            Submitted by: rik5
            Submitted on: Fri 10 Feb 2012 12:31:04 PM PST
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I'm recording a memory leak here on the bug tracker because it should be
noted, but probably can't be fixed anytime soon.

>From valgrind, the memory leak is


==12534== 16 bytes in 2 blocks are definitely lost in loss record 73 of 515
==12534==    at 0x4C27939: operator new[](unsigned long)
(vg_replace_malloc.c:305)
==12534==    by 0x5268953: std::string* no_ctor_new<std::string>(unsigned
long) (oct-mem.h:131)
==12534==    by 0x52683EF: Array<std::string>::ArrayRep::ArrayRep(int)
(Array.h:80)
==12534==    by 0x52678E5: Array<std::string>::Array(dim_vector const&)
(Array.h:196)
==12534==    by 0x675B49F: Array<std::string>::resize2(int, int, std::string
const&) (Array.cc:978)
==12534==    by 0x6755624: Array<std::string>::resize(dim_vector const&,
std::string const&) (Array.cc:1017)
==12534==    by 0x546E2A6: string_vector::resize(int, std::string const&)
(str-vec.h:93)
==12534==    by 0x54E9EAE: load_path::dir_info::get_file_list(std::string
const&) (load-path.cc:206)
==12534==    by 0x54E9912: load_path::dir_info::initialize()
(load-path.cc:126)
==12534==    by 0x54F39F1: load_path::dir_info::dir_info(std::string const&)
(load-path.h:306)
==12534==    by 0x54EBE25: load_path::do_add(std::string const&, bool, bool)
(load-path.cc:658)
==12534==    by 0x54EBAE4: load_path::do_append(std::string const&, bool)
(load-path.cc:605)
==12534==    by 0x54EB8D7: load_path::do_set(std::string const&, bool)
(load-path.cc:584)
==12534==    by 0x54EB5A8: load_path::do_initialize(bool) (load-path.cc:522)
==12534==    by 0x54F34A6: load_path::initialize(bool) (load-path.h:53)
==12534==    by 0x55D024F: octave_main (octave.cc:869)
==12534==    by 0x400768: main (main.c:35)


and also


==12534== 120 bytes in 15 blocks are definitely lost in loss record 419 of
515
==12534==    at 0x4C27939: operator new[](unsigned long)
(vg_replace_malloc.c:305)
==12534==    by 0x5268953: std::string* no_ctor_new<std::string>(unsigned
long) (oct-mem.h:131)
==12534==    by 0x52683EF: Array<std::string>::ArrayRep::ArrayRep(int)
(Array.h:80)
==12534==    by 0x52678E5: Array<std::string>::Array(dim_vector const&)
(Array.h:196)
==12534==    by 0x675B49F: Array<std::string>::resize2(int, int, std::string
const&) (Array.cc:978)
==12534==    by 0x6755624: Array<std::string>::resize(dim_vector const&,
std::string const&) (Array.cc:1017)
==12534==    by 0x546E2A6: string_vector::resize(int, std::string const&)
(str-vec.h:93)
==12534==    by 0x54E9ECE: load_path::dir_info::get_file_list(std::string
const&) (load-path.cc:207)
==12534==    by 0x54E9912: load_path::dir_info::initialize()
(load-path.cc:126)
==12534==    by 0x54F39F1: load_path::dir_info::dir_info(std::string const&)
(load-path.h:306)
==12534==    by 0x54EBE25: load_path::do_add(std::string const&, bool, bool)
(load-path.cc:658)
==12534==    by 0x54EBAE4: load_path::do_append(std::string const&, bool)
(load-path.cc:605)
==12534==    by 0x54EB8D7: load_path::do_set(std::string const&, bool)
(load-path.cc:584)
==12534==    by 0x54EB5A8: load_path::do_initialize(bool) (load-path.cc:522)
==12534==    by 0x54F34A6: load_path::initialize(bool) (load-path.h:53)
==12534==    by 0x55D024F: octave_main (octave.cc:869)
==12534==    by 0x400768: main (main.c:35)


The changeset which introduced the problem is 14156 which I am quoting in its
entirety.


changeset:   14156:d5d3037cbc11
branch:      stable
user:        John W. Eaton <address@hidden>
date:        Fri Jan 06 10:59:15 2012 -0500
summary:     don't call singleton_cleanup_list::cleanup on exit.

diff -r 583d3d6f6fde -r d5d3037cbc11 src/toplev.cc
--- a/src/toplev.cc     Fri Jan 06 10:51:11 2012 -0500
+++ b/src/toplev.cc     Fri Jan 06 10:59:15 2012 -0500
@@ -1082,7 +1082,17 @@
           OCTAVE_SAFE_CALL (flush_octave_stdout, ());
         }
 
-      OCTAVE_SAFE_CALL (singleton_cleanup_list::cleanup, ());
+      // Don't call singleton_cleanup_list::cleanup until we have the
+      // problems with registering/unregistering types worked out.  For
+      // example, uncomment the following line, then use the make_int
+      // function from the examples directory to create an integer
+      // object and then exit Octave.  Octave should crash with a
+      // segfault when cleaning up the typinfo singleton.  We need some
+      // way to force new octave_value_X types that are created in
+      // .oct files to be unregistered when the .oct file shared library
+      // is unloaded.
+      //
+      // OCTAVE_SAFE_CALL (singleton_cleanup_list::cleanup, ());
 
       OCTAVE_SAFE_CALL (octave_chunk_buffer::clear, ());
     }


>From the comments, it appears that much mork work needs to be done before this
leak can be resolved.  On the other hand, it will be trivial to uncomment the
necessary line once support for registering/unregistering types has been
added.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35502>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/