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

 
 

bug #55415: Memory leaks during "make check"

Submitted by:  Rik <rik5>
Submitted on:  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

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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>
Project 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
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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.5