bugGNU Octave - Bugs: bug #35502, Memory leak in load-path.cc

 
 

bug #35502: Memory leak in load-path.cc

Submitter:  Rik <rik5>
Submitted:  Fri 10 Feb 2012 08:31:04 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 15 Aug 2017 06:35:35 AM UTC, comment #1: 

Closing report.  This bug is very old.  More recent checking with Address Sanitizer does not reveal this problem.

Rik <rik5>
Group administrator
Fri 10 Feb 2012 08:31:04 PM UTC, original submission:  

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 <jwe@octave.org>
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.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-15 rik5 Open/ClosedOpen Closed
    2013-10-17 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code