bugGNU Octave - Bugs: bug #40233, Memory leak in oct-shlib

 
 

bug #40233: Memory leak in oct-shlib

Submitter:  Rik <rik5>
Submitted:  Thu 10 Oct 2013 03:47:31 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Invalid / Not an Octave Bug 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
   

Wed 16 Oct 2013 03:02:31 PM UTC, comment #3: 

I can't see that Octave is doing anything wrong when it opens shared libraries, so I think this leak is outside of our code.  Closing report.

Rik <rik5>
Group administrator
Fri 11 Oct 2013 05:38:17 PM UTC, comment #2: 

I agree that this isn't a threat to the stability of Octave.  However, I wouldn't close the report because there is definitely something going on.  The example I listed lost only 56 bytes which is inconsequential.  However over a full run of the test suite, 4096 bytes were lost.  Although the growth is very slow, it doesn't appear that there is a cap.

Enough changes have taken place that the whole test suite needs to be re-run under valgrind (and I know you are doing that from a different bug report).  Perhaps this has been fixed.  If not, I would try running the test suite and executing a 'clear -all' at the end to see if this is only valgrind not recognizing objects that would be cleaned up in the course of normal events.

Rik <rik5>
Group administrator
Thu 10 Oct 2013 08:57:43 PM UTC, comment #1: 

I haven't investigated, but I suspect that this is another case of allocating resources and not explicitly cleaning them up before Octave exits.

If this is due to loading .oct files, then I'm only concerned about it if Octave is not properly freeing memory if you do something like repeatedly call a function defined in a .oct file, then clear it.  If that causes Octave to grow without bound, then there is an actual leak we should worry about.

If I do


x = rand (10);
while (1)
  [q, r] = qr (x);
  clear qr
end


Octave does not appear to grow.  I can verify with lsof that qr.oct is loaded when I call it and closed when I clear it.

So maybe we should close this report?

John W. Eaton <jwe>
Group administrator
Thu 10 Oct 2013 03:47:31 AM UTC, original submission:  

The leak is in the shared library code oct-shlib.  Perhaps helpful, or perhaps a red herring, it is a PKG_ADD command that starts the leak sequence.


==16089== 56 (24 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 678 of 1,172
==16089==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16089==    by 0x17EBA951: ???
==16089==    by 0x17EBAE20: ???
==16089==    by 0x17EBB101: ???
==16089==    by 0x17C3363D: ???
==16089==    by 0x400F305: call_init.part.0 (dl-init.c:85)
==16089==    by 0x400F3DE: _dl_init (dl-init.c:52)
==16089==    by 0x4013AD9: dl_open_worker (dl-open.c:549)
==16089==    by 0x400F175: _dl_catch_error (dl-error.c:178)
==16089==    by 0x4013319: _dl_open (dl-open.c:639)
==16089==    by 0xBFE8F25: dlopen_doit (dlopen.c:67)
==16089==    by 0x400F175: _dl_catch_error (dl-error.c:178)
==16089==    by 0xBFE952E: _dlerror_run (dlerror.c:164)
==16089==    by 0xBFE8FC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
==16089==    by 0x6F1313F: octave_dlopen_shlib::octave_dlopen_shlib(std::string const&) (oct-shlib.cc:196)
==16089==    by 0x6F133BA: octave_shlib::shlib_rep::new_instance(std::string const&) (oct-shlib.cc:508)
==16089==    by 0x6F12F05: octave_shlib::shlib_rep::get_instance(std::string const&, bool) (oct-shlib.cc:108)
==16089==    by 0x597DF48: octave_shlib::octave_shlib(std::string const&, bool) (oct-shlib.h:116)
==16089==    by 0x597DFCC: octave_shlib::open(std::string const&) (in /home/rik/wip/Projects_Mine/octave-dbg/libinterp/.libs/liboctinterp.so.1.0.1)
==16089==    by 0x597D705: octave_dynamic_loader::do_load_oct(std::string const&, std::string const&, bool) (dynamic-ld.cc:270)
==16089==    by 0x597DC49: octave_dynamic_loader::load_oct(std::string const&, std::string const&, bool) (dynamic-ld.cc:423)
==16089==    by 0x58B62B5: load_fcn_from_file(std::string const&, std::string const&, std::string const&, std::string const&, bool) (oct-parse.yy:3518)
==16089==    by 0x5C54717: symbol_table::fcn_info::fcn_info_rep::find_autoload() (symtab.cc:972)
==16089==    by 0x5C53BF1: symbol_table::fcn_info::fcn_info_rep::xfind(octave_value_list const&, bool) (symtab.cc:772)
==16089==    by 0x5C532E7: symbol_table::fcn_info::fcn_info_rep::find(octave_value_list const&, bool) (symtab.cc:616)
==16089==    by 0x5C581E1: symbol_table::fcn_info::find(octave_value_list const&, bool) (symtab.h:988)
==16089==    by 0x5C56418: symbol_table::do_find(std::string const&, octave_value_list const&, bool, bool) (symtab.cc:1348)
==16089==    by 0x5C55623: symbol_table::find(std::string const&, octave_value_list const&, bool, bool) (symtab.cc:1149)
==16089==    by 0x5C55877: symbol_table::find_function(std::string const&, octave_value_list const&, bool) (symtab.cc:1184)
==16089==    by 0x5C51689: symbol_table::symbol_record::find(octave_value_list const&) const (symtab.cc:138)
==16089==    by 0x5873F3B: tree_identifier::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-id.cc:70)
==16089==    by 0x5874A0C: tree_identifier::rvalue(int) (pt-id.h:108)
==16089==    by 0x5874225: tree_identifier::rvalue1(int) (pt-id.cc:115)
==16089==    by 0x58763C9: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:327)
==16089==    by 0x58760C6: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==16089==    by 0x5876BC5: tree_index_expression::rvalue1(int) (pt-idx.cc:425)
==16089==    by 0x5872682: tree_expression::is_logically_true(char const*) (pt-exp.cc:43)
==16089==    by 0x586FB99: tree_evaluator::visit_if_command_list(tree_if_command_list&) (pt-eval.cc:581)
==16089==    by 0x588E80F: tree_if_command_list::accept(tree_walker&) (pt-select.cc:83)
==16089==    by 0x586FA77: tree_evaluator::visit_if_command(tree_if_command&) (pt-eval.cc:563)
==16089==    by 0x588EA2B: tree_if_command::accept(tree_walker&) (pt-select.cc:108)
==16089==    by 0x5870083: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)
==16089==    by 0x5890AD3: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==16089==    by 0x58703D5: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==16089==    by 0x58910F3: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==16089==    by 0x5801B0D: octave_user_script::do_multi_index_op(int, octave_value_list const&) (ov-usr-fcn.cc:153)
==16089==    by 0x58B7682: source_file(std::string const&, std::string const&, bool, bool, std::string const&) (oct-parse.yy:3769)
==16089==    by 0x5B37216: execute_pkg_add_or_del(std::string const&, std::string const&) (load-path.cc:1983)
==16089==    by 0x5B37324: execute_pkg_add(std::string const&) (load-path.cc:1989)
==16089==    by 0x5B3195A: load_path::do_set(std::string const&, bool, bool) (load-path.cc:632)



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 jwe (Posted a comment)
  • -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
    2013-10-16 rik5 StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code