bugGNU Octave - Bugs: bug #40231, Memory leaks when parser fails to...

 
 

bug #40231: Memory leaks when parser fails to parse

Submitter:  Rik <rik5>
Submitted:  Thu 10 Oct 2013 02:56:54 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed 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
   

Jump to the original submission

Thu 17 Oct 2013 04:53:56 PM UTC, comment #17: 

All the leaks seem to be plugged which is good news for Octave.  Closing report.

Rik <rik5>
Group administrator
Thu 17 Oct 2013 04:34:23 PM UTC, comment #16: 

Thanks for finding this test case.  I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/9f6e4e5c2bac

It seems to fix the problem for me.  If you agree, please close this report.

John W. Eaton <jwe>
Group administrator
Wed 16 Oct 2013 06:45:38 PM UTC, comment #15: 

I narrowed down the memory leak in Feval to this test


%!test
%! clear myerr;
%! try
%!   error ("user-defined error");
%! catch myerr
%!   assert (myerr.message, "user-defined error");
%! end_try_catch


The resulting valgrind output is


==7036== 48 bytes in 1 blocks are definitely lost in loss record 368 of 575
==7036==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7036==    by 0x5C901A4: tree_statement* make_statement<tree_expression>(tree_expression*) (oct-parse.yy:115)
==7036==    by 0x5C809A8: octave_push_parse(octave_pstate*, int, YYSTYPE const*, octave_base_parser&) (oct-parse.yy:399)
==7036==    by 0x5C7FD70: octave_pull_parse(octave_pstate*, octave_base_parser&) (oct-parse.cc:3964)
==7036==    by 0x5C7FCED: octave_parse(octave_base_parser&) (oct-parse.cc:3932)
==7036==    by 0x5C8B609: octave_parser::run() (oct-parse.yy:3412)
==7036==    by 0x5C8ECEE: eval_string(std::string const&, bool, int&, int) (oct-parse.yy:4261)
==7036==    by 0x5C8F1CC: eval_string(octave_value const&, bool, int&, int) (oct-parse.yy:4346)
==7036==    by 0x5C8F32F: Feval(octave_value_list const&, int) (oct-parse.yy:4410)
==7036==    by 0x5B3C640: octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:131)
==7036==    by 0x5B3C2E7: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:64)
==7036==    by 0x5B3C1D5: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-builtin.cc:47)
==7036==    by 0x5BE2EE7: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==7036==    by 0x5BE2F8F: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==7036==    by 0x5C4BC8E: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==7036==    by 0x5C4B3E6: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==7036==    by 0x5C4BEE5: tree_index_expression::rvalue1(int) (pt-idx.cc:425)
==7036==    by 0x5C4548A: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:747)
==7036==    by 0x5C65DF3: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==7036==    by 0x5C456F5: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==7036==    by 0x5C66413: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==7036==    by 0x5C44F04: tree_evaluator::visit_if_command_list(tree_if_command_list&) (pt-eval.cc:588)
==7036==    by 0x5C63B2F: tree_if_command_list::accept(tree_walker&) (pt-select.cc:83)
==7036==    by 0x5C44D97: tree_evaluator::visit_if_command(tree_if_command&) (pt-eval.cc:563)
==7036==    by 0x5C63D4B: tree_if_command::accept(tree_walker&) (pt-select.cc:108)
==7036==    by 0x5C453A3: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)
==7036==    by 0x5C65DF3: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==7036==    by 0x5C456F5: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==7036==    by 0x5C66413: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==7036==    by 0x5C45AE1: tree_evaluator::visit_try_catch_command(tree_try_catch_command&) (pt-eval.cc:910)
==7036==    by 0x5C4753B: tree_try_catch_command::accept(tree_walker&) (pt-except.cc:72)
==7036==    by 0x5C453A3: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)
==7036==    by 0x5C65DF3: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==7036==    by 0x5C456F5: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==7036==    by 0x5C66413: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==7036==    by 0x5C44F04: tree_evaluator::visit_if_command_list(tree_if_command_list&) (pt-eval.cc:588)
==7036==    by 0x5C63B2F: tree_if_command_list::accept(tree_walker&) (pt-select.cc:83)
==7036==    by 0x5C44D97: tree_evaluator::visit_if_command(tree_if_command&) (pt-eval.cc:563)
==7036==    by 0x5C63D4B: tree_if_command::accept(tree_walker&) (pt-select.cc:108)
==7036==    by 0x5C453A3: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)
==7036==    by 0x5C65DF3: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==7036==    by 0x5C456F5: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==7036==    by 0x5C66413: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==7036==    by 0x5C44105: tree_evaluator::visit_simple_for_command(tree_simple_for_command&) (pt-eval.cc:369)
==7036==    by 0x5C4EF2B: tree_simple_for_command::accept(tree_walker&) (pt-loop.cc:125)
==7036==    by 0x5C453A3: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)
==7036==    by 0x5C65DF3: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==7036==    by 0x5C456F5: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==7036==    by 0x5C66413: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==7036==    by 0x5BD86D6: octave_user_function::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-usr-fcn.cc:588)


For simplicity, I've attached the bad file as try.tst to this report.



(file #29389)

Rik <rik5>
Group administrator
Tue 15 Oct 2013 11:58:13 PM UTC, comment #14: 

The leak through Feval and sparse was a true leak in the Sparse constructor, not the parser.  I plugged it here (http://hg.savannah.gnu.org/hgweb/octave/rev/f4b0430fa5fd).

Rik <rik5>
Group administrator
Sat 12 Oct 2013 11:34:28 PM UTC, comment #13: 

Oh good, so we have more than one leak path.  Sigh

Rik <rik5>
Group administrator
Sat 12 Oct 2013 08:21:57 PM UTC, comment #12: 

This doesn't look like the same leak.  The one previously was inside the parser, apparently related to octave_base_parser::make_constant.

John W. Eaton <jwe>
Group administrator
Sat 12 Oct 2013 08:16:14 PM UTC, comment #11: 

Thanks, I'll take a look at it.

John W. Eaton <jwe>
Group administrator
Sat 12 Oct 2013 07:52:53 PM UTC, comment #10: 

Attached is a simple one-line program which makes use of %!error which shows a leak through Feval.


test eval_leak.tst
exit


where eval_leak.tst is just


%!error sparse (1,[2,3],[1,2,3])




(file #29364)

Rik <rik5>
Group administrator
Sat 12 Oct 2013 07:38:23 PM UTC, comment #9: 

Maybe not too painful.  Just running the tests for in sparse.tst are enough to uncover one example.  Of course, sparse.tst has 1204 tests so bisecting that will still take some time.

I ran Octave under valgrind and then


cd test
test sparse.tst
exit


The leak report is below, and there is a big distance from the Feval to the actual leak which complicates debugging.


==12359== 56 (40 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 395 of 600
==12359==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12359==    by 0x6FA4E17: Sparse<double>::Sparse(Array<double> const&, idx_vector const&, idx_vector const&, int, int, bool, int) (Sparse.cc:304)
==12359==    by 0x5F2CD84: MSparse<double>::MSparse(Array<double> const&, idx_vector const&, idx_vector const&, int, int, bool, int) (MSparse.h:64)
==12359==    by 0x5F2CC78: SparseMatrix::SparseMatrix(Array<double> const&, idx_vector const&, idx_vector const&, int, int, bool, int) (dSparse.h:81)
==12359==    by 0x601990D: Fsparse(octave_value_list const&, int) (sparse.cc:200)
==12359==    by 0x5B3B630: octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:131)
==12359==    by 0x5B3B2D7: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:64)
==12359==    by 0x5B3B1C5: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-builtin.cc:47)
==12359==    by 0x5BE1E47: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==12359==    by 0x5BE1EEF: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==12359==    by 0x5C4ABEE: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==12359==    by 0x5C4A346: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==12359==    by 0x5C4AE45: tree_index_expression::rvalue1(int) (pt-idx.cc:425)
==12359==    by 0x5C443EA: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:747)
==12359==    by 0x5C64D53: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==12359==    by 0x5C44655: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==12359==    by 0x5C65373: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==12359==    by 0x5BD7636: octave_user_function::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-usr-fcn.cc:588)
==12359==    by 0x5BD6F25: octave_user_function::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-usr-fcn.cc:437)
==12359==    by 0x5BD6E13: octave_user_function::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-usr-fcn.cc:420)
==12359==    by 0x5BE1E47: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==12359==    by 0x5BE1EEF: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==12359==    by 0x5C4ABEE: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==12359==    by 0x5C4A346: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==12359==    by 0x5C8DDCC: eval_string(std::string const&, bool, int&, int) (oct-parse.yy:4255)
==12359==    by 0x5C8E12C: eval_string(octave_value const&, bool, int&, int) (oct-parse.yy:4308)
==12359==    by 0x5C8E28F: Feval(octave_value_list const&, int) (oct-parse.yy:4372)
==12359==    by 0x5B3B630: octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:131)
==12359==    by 0x5B3B2D7: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:64)
==12359==    by 0x5B3B1C5: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-builtin.cc:47)
==12359==    by 0x5BE1E47: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==12359==    by 0x5BE1EEF: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==12359==    by 0x5C4ABEE: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==12359==    by 0x5C4A346: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==12359==    by 0x5C4AE45: tree_index_expression::rvalue1(int) (pt-idx.cc:425)
==12359==    by 0x5C443EA: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:747)
==12359==    by 0x5C64D53: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==12359==    by 0x5C44655: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==12359==    by 0x5C65373: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==12359==    by 0x5C44A41: tree_evaluator::visit_try_catch_command(tree_try_catch_command&) (pt-eval.cc:910)
==12359==    by 0x5C4649B: tree_try_catch_command::accept(tree_walker&) (pt-except.cc:72)
==12359==    by 0x5C44303: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)
==12359==    by 0x5C64D53: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==12359==    by 0x5C44655: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==12359==    by 0x5C65373: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==12359==    by 0x5C43E64: tree_evaluator::visit_if_command_list(tree_if_command_list&) (pt-eval.cc:588)
==12359==    by 0x5C62A8F: tree_if_command_list::accept(tree_walker&) (pt-select.cc:83)
==12359==    by 0x5C43CF7: tree_evaluator::visit_if_command(tree_if_command&) (pt-eval.cc:563)
==12359==    by 0x5C62CAB: tree_if_command::accept(tree_walker&) (pt-select.cc:108)
==12359==    by 0x5C44303: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:721)



Rik <rik5>
Group administrator
Sat 12 Oct 2013 05:13:24 AM UTC, comment #8: 

Valgrind still showed a leak in the parser inside a call to eval when I ran the full set of tests.  It's not obvious to me what could cause it and the valgrind output doesn't point to which test(s) is (are) causing it, so I don't know how to debug it.  I guess we could bisect the test suite until we find the particular test that generates the leak, but that sounds painful.

John W. Eaton <jwe>
Group administrator
Sat 12 Oct 2013 04:48:40 AM UTC, comment #7: 

Seems to work for the simple cases I tried.  Final judgement is the full 'make check' you are running.

Rik <rik5>
Group administrator
Fri 11 Oct 2013 04:31:52 PM UTC, comment #6: 

I also checked in this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/bd0a84de3375

It should take care of most (all?) other cases in which we need to delete partially constructed parse trees when an error occurs.

I'm running the test suite with valgrind now.  If that doesn't show any leaks coming from inside the parser, I'll close this report.

John W. Eaton <jwe>
Group administrator
Fri 11 Oct 2013 02:16:50 PM UTC, comment #5: 

I checked in the following changeset.

http://hg.savannah.gnu.org/hgweb/octave/rev/1e8f8900a041

It seems to avoid the leak for the parse error in eval but not for "if (1) endfor".  I thought it might fix both, but apparently not.  I'll take another look.


John W. Eaton <jwe>
Group administrator
Thu 10 Oct 2013 10:29:14 PM UTC, comment #4: 

This was never marked as a blocker for the release, but I will re-title the report.  The other report, for evalin, I will close since it certainly the same thing.

Rik <rik5>
Group administrator
Thu 10 Oct 2013 09:06:23 PM UTC, comment #3: 

I don't think this problem is specific to switch statements or eval.  You can also see a leak if you just do


if (1) endfor


at the command prompt.  We surely need better error recovery in the parser, but I don't think this is a new issue.  I don't think it is worth blocking the release for it as I'm sure this bug has been around for as long as Octave.

John W. Eaton <jwe>
Group administrator
Thu 10 Oct 2013 07:43:31 PM UTC, comment #2: 

I got the whole ginormous report after running the test suite under valgrind so I don't have a clear idea which test caused the failure.  I seem to remember that switch statements were a problem (see bug #35154).

I just tried the demo code there


eval("switch 1 default 1; endswitch")


and I get a memory leak in eval shown below.


==32481== 106 (56 direct, 50 indirect) bytes in 1 blocks are definitely lost in loss record 453 of 579
==32481==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32481==    by 0x5C98DAC: octave_base_parser::make_constant(int, token*) (oct-parse.yy:1908)
==32481==    by 0x5C91D34: octave_push_parse(octave_pstate*, int, YYSTYPE const*, octave_base_parser&) (oct-parse.yy:413)
==32481==    by 0x5C90D7E: octave_pull_parse(octave_pstate*, octave_base_parser&) (oct-parse.cc:2155)
==32481==    by 0x5C90CFB: octave_parse(octave_base_parser&) (oct-parse.cc:2123)
==32481==    by 0x5C9C657: octave_parser::run() (oct-parse.yy:3291)
==32481==    by 0x5C9FD3C: eval_string(std::string const&, bool, int&, int) (oct-parse.yy:4140)
==32481==    by 0x5CA021A: eval_string(octave_value const&, bool, int&, int) (oct-parse.yy:4225)
==32481==    by 0x5CA037D: Feval(octave_value_list const&, int) (oct-parse.yy:4289)
==32481==    by 0x5B3F1C0: octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:131)
==32481==    by 0x5B3EE67: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:64)
==32481==    by 0x5B3ED55: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-builtin.cc:47)
==32481==    by 0x5BF4F0B: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==32481==    by 0x5BF4FB3: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==32481==    by 0x5C5DAC2: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==32481==    by 0x5C5D21A: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==32481==    by 0x5C5DD19: tree_index_expression::rvalue1(int) (pt-idx.cc:425)
==32481==    by 0x5C57346: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:747)
==32481==    by 0x5C77B6F: tree_statement::accept(tree_walker&) (pt-stmt.cc:178)
==32481==    by 0x5C575B1: tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:797)
==32481==    by 0x5C7818F: tree_statement_list::accept(tree_walker&) (pt-stmt.cc:291)
==32481==    by 0x6071C0D: main_loop() (toplev.cc:573)
==32481==    by 0x57CA2C3: octave_execute_interpreter (octave.cc:1031)
==32481==    by 0x402CA0: main (main.cc:49)



Rik <rik5>
Group administrator
Thu 10 Oct 2013 06:17:07 PM UTC, comment #1: 

I can't seem to duplicate this with a simple "eval ('1')".  Do you have any clue about what is being evaluated to trigger this leak?

John W. Eaton <jwe>
Group administrator
Thu 10 Oct 2013 02:56:54 AM UTC, original submission:  

Along with evalin, reported earlier, there appears to be a leak in eval.


==16089== 106 (56 direct, 50 indirect) bytes in 1 blocks are definitely lost in loss record 801 of 1,172
==16089==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16089==    by 0x58B1730: octave_base_parser::make_constant(int, token*) (oct-parse.yy:1862)
==16089==    by 0x58AAC98: octave_push_parse(octave_pstate*, int, YYSTYPE const*, octave_base_parser&) (oct-parse.yy:413)
==16089==    by 0x58A9CE2: octave_pull_parse(octave_pstate*, octave_base_parser&) (oct-parse.cc:2099)
==16089==    by 0x58A9C5F: octave_parse(octave_base_parser&) (oct-parse.cc:2067)
==16089==    by 0x58B4FDB: octave_parser::run() (oct-parse.yy:3245)
==16089==    by 0x58B86C0: eval_string(std::string const&, bool, int&, int) (oct-parse.yy:4094)
==16089==    by 0x58B8B9E: eval_string(octave_value const&, bool, int&, int) (oct-parse.yy:4179)
==16089==    by 0x58B8D01: Feval(octave_value_list const&, int) (oct-parse.yy:4243)
==16089==    by 0x57673B0: octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:131)
==16089==    by 0x5767057: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:64)
==16089==    by 0x5766F45: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-builtin.cc:47)
==16089==    by 0x580DBC7: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==16089==    by 0x580DC6F: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==16089==    by 0x587696E: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==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 0x587016A: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:747)
==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 0x58033B6: octave_user_function::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-usr-fcn.cc:588)
==16089==    by 0x5802CA5: octave_user_function::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-usr-fcn.cc:437)
==16089==    by 0x5802B93: octave_user_function::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-usr-fcn.cc:420)
==16089==    by 0x580DBC7: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==16089==    by 0x580DC6F: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==16089==    by 0x587696E: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==16089==    by 0x58760C6: tree_index_expression::rvalue(int) (pt-idx.cc:284)
==16089==    by 0x58B883E: eval_string(std::string const&, bool, int&, int) (oct-parse.yy:4126)
==16089==    by 0x58B8B9E: eval_string(octave_value const&, bool, int&, int) (oct-parse.yy:4179)
==16089==    by 0x58B8D01: Feval(octave_value_list const&, int) (oct-parse.yy:4243)
==16089==    by 0x57673B0: octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:131)
==16089==    by 0x5767057: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov-builtin.cc:64)
==16089==    by 0x5766F45: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov-builtin.cc:47)
==16089==    by 0x580DBC7: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (ov.cc:1269)
==16089==    by 0x580DC6F: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (ov.cc:1280)
==16089==    by 0x587696E: tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:414)
==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 0x587016A: tree_evaluator::visit_statement(tree_statement&) (pt-eval.cc:747)
==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 0x58707C1: tree_evaluator::visit_try_catch_command(tree_try_catch_command&) (pt-eval.cc:910)
==16089==    by 0x587221B: tree_try_catch_command::accept(tree_walker&) (pt-except.cc:72)
==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 0x586FBE4: tree_evaluator::visit_if_command_list(tree_if_command_list&) (pt-eval.cc:588)



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 #29389:  try.tst added by rik5 (148B - application/octet-stream)
file #29364:  eval_leak.tst added by rik5 (33B - application/octet-stream)

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-17 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2013-10-17 jwe StatusConfirmed Ready For Test
    2013-10-16 rik5 Attached File- Added try.tst, #29389
    2013-10-12 rik5 Attached File- Added eval_leak.tst, #29364
    2013-10-10 rik5 StatusNone Confirmed
        SummaryMemory leak in eval Memory leaks when parser fails to parse

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code