bugGNU Octave - Bugs: bug #55415, Memory leaks during "make...

 
 

bug #55415: Memory leaks during "make check"

Submitter:  Rik <rik5>
Submitted:  Mon 07 Jan 2019 11:17:58 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 5.0.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 19 Jan 2019 12:00:12 AM UTC, comment #3: 

This isn't much and it isn't worth gating the 5.0 release on.

Rik <rik5>
Group administrator
Fri 18 Jan 2019 11:59:24 PM UTC, comment #2: 

Besides the one instance of feval, there are a few leaks related to octave_builtin::call which look like this


Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7ff2167e2458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7ff1ba762c6b  (<unknown module>)
    #2 0x7ff1ba762262  (<unknown module>)
    #3 0x7ff1ba767888  (<unknown module>)
    #4 0x7ff1ba76c13c  (<unknown module>)
    #5 0x7ff21517b908 in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const /usr/include/c++/7/bits/std_function.h:706
    #6 0x7ff1ba767f5e  (<unknown module>)
    #7 0x7ff1ba765fac  (<unknown module>)
    #8 0x7ff1ba75f610  (<unknown module>)
    #9 0x7ff1ba75e7e2  (<unknown module>)
    #10 0x7ff2144e322f in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) libinterp/octave-value/ov-builtin.cc:65
    #11 0x7ff21495643f in octave::tree_evaluator::visit_index_expression(octave::tree_index_expression&) libinterp/parse-tree/pt-eval.cc:2008
    #12 0x7ff214991452 in octave::tree_index_expression::accept(octave::tree_walker&) libinterp/parse-tree/pt-idx.h:102
    #13 0x7ff2145b6985 in octave::tree_evaluator::evaluate(octave::tree_expression*, int) libinterp/parse-tree/pt-eval.h:312
    #14 0x7ff21495e7a7 in octave::tree_evaluator::visit_statement(octave::tree_statement&) libinterp/parse-tree/pt-eval.cc:2776
    #15 0x7ff2149a7b9a in octave::tree_statement::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:119
    #16 0x7ff21495ee7f in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) libinterp/parse-tree/pt-eval.cc:2845
    #17 0x7ff2145b7564 in octave::tree_statement_list::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:194
    #18 0x7ff214960f82 in octave::tree_evaluator::visit_unwind_protect_command(octave::tree_unwind_protect_command&) libinterp/parse-tree/pt-eval.cc:3101
    #19 0x7ff2149895ec in octave::tree_unwind_protect_command::accept(octave::tree_walker&) libinterp/parse-tree/pt-except.h:148
    #20 0x7ff21495e5d2 in octave::tree_evaluator::visit_statement(octave::tree_statement&) libinterp/parse-tree/pt-eval.cc:2754
    #21 0x7ff2149a7b9a in octave::tree_statement::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:119
    #22 0x7ff21495ee7f in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) libinterp/parse-tree/pt-eval.cc:2845
    #23 0x7ff2145b7564 in octave::tree_statement_list::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:194
    #24 0x7ff214960f82 in octave::tree_evaluator::visit_unwind_protect_command(octave::tree_unwind_protect_command&) libinterp/parse-tree/pt-eval.cc:3101
    #25 0x7ff2149895ec in octave::tree_unwind_protect_command::accept(octave::tree_walker&) libinterp/parse-tree/pt-except.h:148
    #26 0x7ff21495e5d2 in octave::tree_evaluator::visit_statement(octave::tree_statement&) libinterp/parse-tree/pt-eval.cc:2754
    #27 0x7ff2149a7b9a in octave::tree_statement::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:119
    #28 0x7ff21495ee7f in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) libinterp/parse-tree/pt-eval.cc:2845
    #29 0x7ff2145b7564 in octave::tree_statement_list::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:194


Rik <rik5>
Group administrator
Mon 14 Jan 2019 05:58:16 AM UTC, comment #1: 

There are some leaks associated with putenv, which are completely known and unavoidable.  The only thing that seems different from the baseline besides putenv is a few leaks like this one


Direct leak of 448 byte(s) in 4 object(s) allocated from:
    #0 0x7f2f4c8a5458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f2eeeebac6b  (<unknown module>)
    #2 0x7f2eeeeba262  (<unknown module>)
    #3 0x7f2eeeebf888  (<unknown module>)
    #4 0x7f2eeeec413c  (<unknown module>)
    #5 0x7f2f4b23eae2 in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const /usr/include/c++/7/bits/std_function.h:706
    #6 0x7f2eeeebff5e  (<unknown module>)
    #7 0x7f2eeeebdfac  (<unknown module>)
    #8 0x7f2eeeeb7610  (<unknown module>)
    #9 0x7f2eeeeb67e2  (<unknown module>)
    #10 0x7f2f4a5a62ad in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) libinterp/octave-value/ov-builtin.cc:65
    #11 0x7f2f4a9b3d63 in octave::feval(octave_function*, octave_value_list const&, int) libinterp/parse-tree/oct-parse.yy:5213
    #12 0x7f2f4a9b4059 in octave::feval(octave_value&, octave_value_list const&, int) libinterp/parse-tree/oct-parse.yy:5224
    #13 0x7f2f4a6f8b2c in octave_fcn_handle::call(int, octave_value_list const&) libinterp/octave-value/ov-fcn-handle.cc:219
    #14 0x7f2f4a6f78f7 in octave_fcn_handle::subsref(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<octave_value_list, std::allocator<octave_value_list> > const&, int) libinterp/octave-value/ov-fcn-handle.cc:115
    #15 0x7f2f4a811961 in octave_value::subsref(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<octave_value_list, std::allocator<octave_value_list> > const&, int) libinterp/octave-value/ov.cc:1420
    #16 0x7f2f4aa1ac03 in octave::tree_evaluator::visit_index_expression(octave::tree_index_expression&) libinterp/parse-tree/pt-eval.cc:2158
    #17 0x7f2f4aa54cb2 in octave::tree_index_expression::accept(octave::tree_walker&) libinterp/parse-tree/pt-idx.h:102
    #18 0x7f2f4a67a219 in octave::tree_evaluator::evaluate(octave::tree_expression*, int) libinterp/parse-tree/pt-eval.h:312
    #19 0x7f2f4aa20d1e in octave::tree_evaluator::visit_simple_assignment(octave::tree_simple_assignment&) libinterp/parse-tree/pt-eval.cc:2680
    #20 0x7f2f4a9f823e in octave::tree_simple_assignment::accept(octave::tree_walker&) libinterp/parse-tree/pt-assign.h:84
    #21 0x7f2f4a67a219 in octave::tree_evaluator::evaluate(octave::tree_expression*, int) libinterp/parse-tree/pt-eval.h:312
    #22 0x7f2f4aa22007 in octave::tree_evaluator::visit_statement(octave::tree_statement&) libinterp/parse-tree/pt-eval.cc:2775
    #23 0x7f2f4aa6b3fa in octave::tree_statement::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:119
    #24 0x7f2f4aa226df in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) libinterp/parse-tree/pt-eval.cc:2844
    #25 0x7f2f4a67adf8 in octave::tree_statement_list::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:194
    #26 0x7f2f4aa13351 in octave::tree_evaluator::visit_simple_for_command(octave::tree_simple_for_command&) libinterp/parse-tree/pt-eval.cc:1295
    #27 0x7f2f4aa5b746 in octave::tree_simple_for_command::accept(octave::tree_walker&) libinterp/parse-tree/pt-loop.h:219
    #28 0x7f2f4aa21e32 in octave::tree_evaluator::visit_statement(octave::tree_statement&) libinterp/parse-tree/pt-eval.cc:2753
    #29 0x7f2f4aa6b3fa in octave::tree_statement::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:119


Don't know how to go about finding out whate the problem is.  It appears to be feval, which means it might be a user function leaking memory.

Rik <rik5>
Group administrator
Mon 07 Jan 2019 11:17:58 PM UTC, original submission:  

To get a baseline level of memory leaks I ran


./run-octave -f -q --eval "exit" |& tee baseline.leak.log


Next, I ran


make check |& tee makecheck.leak.log


The two log files are xz-compressed and attached.

The direct leaks don't look bad.  In the indirect leaks I see some that seem to be related to the parser and symbol table that might need review.


Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45965:  makecheck.leak.log.xz added by rik5 (37KiB - application/x-xz)
file #45964:  baseline.leak.log.xz added by rik5 (32KiB - application/x-xz)

 

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)
  • -email is unavailable- added by rik5
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-28 rik5 Open/ClosedOpen Closed
    2019-01-19 rik5 StatusNone Confirmed
    2019-01-14 rik5 Attached File- Added makecheck.leak.log.xz, #45965
    2019-01-14 rik5 Attached File- Added baseline.leak.log.xz, #45964
    2019-01-07 rik5 Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code