[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #55415] Memory leaks during "make check"
From: |
Rik |
Subject: |
[Octave-bug-tracker] [bug #55415] Memory leaks during "make check" |
Date: |
Mon, 14 Jan 2019 00:58:16 -0500 (EST) |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko |
Follow-up Comment #1, bug #55415 (project octave):
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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55415>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/