octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #52123] Memory leak in cdef_manager::initializ


From: Piotr Held
Subject: [Octave-bug-tracker] [bug #52123] Memory leak in cdef_manager::initialize ()
Date: Tue, 26 Sep 2017 18:46:40 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36

URL:
  <http://savannah.gnu.org/bugs/?52123>

                 Summary: Memory leak in cdef_manager::initialize ()
                 Project: GNU Octave
            Submitted by: jsoh425
            Submitted on: Tue 26 Sep 2017 10:46:39 PM UTC
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Segfault, Bus Error, etc.
                  Status: None
             Assigned to: None
         Originator Name: Piotr Held
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

I have been getting a large printout memory leak every time I would run Octave
with the addresss sanitizer. The printout would look more or less like this:


Indirect leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x7f2b7fa6ed70 in operator new[](unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2d70)
    #1 0x7f2b7e4c2155 in Array<char>::ArrayRep::ArrayRep(long)
../build_source/liboctave/array/Array.h:159
    #2 0x7f2b7e4bd837 in Array<char>::Array(dim_vector const&)
../build_source/liboctave/array/Array.h:265
    #3 0x7f2b7cac9819 in Array<char>::resize1(long, char const&)
(/mnt/sdb2/Projects/last_octave_ever/dbg-build/liboctave/.libs/liboctave.so.4+0x54f819)
    #4 0x7f2b7cac9abf in Array<char>::resize1(long)
../build_source/liboctave/array/Array.h:612
    #5 0x7f2b7ce28c1c in
charNDArray::charNDArray(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
../build_source/liboctave/array/chNDArray.cc:65
    #6 0x7f2b7ea2b92f in
octave_char_matrix::octave_char_matrix(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
../build_source/libinterp/octave-value/ov-ch-mat.h:73
    #7 0x7f2b7ea2bc9a in
octave_char_matrix_str::octave_char_matrix_str(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
../build_source/libinterp/octave-value/ov-str-mat.h:74
    #8 0x7f2b7ea2bf10 in
octave_char_matrix_sq_str::octave_char_matrix_sq_str(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
../build_source/libinterp/octave-value/ov-str-mat.h:203
    #9 0x7f2b7e9fd460 in
octave_value::octave_value(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, char)
../build_source/libinterp/octave-value/ov.cc:780
    #10 0x7f2b7e8e5677 in
cdef_class::cdef_class_rep::set_name(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
../build_source/libinterp/octave-value/ov-classdef.h:686
    #11 0x7f2b7e8e60d0 in
cdef_class::cdef_class(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::__cxx11::list<cdef_class, std::allocator<cdef_class> > const&)
../build_source/libinterp/octave-value/ov-classdef.h:827
    #12 0x7f2b7e8c9275 in make_class
../build_source/libinterp/octave-value/ov-classdef.cc:647
    #13 0x7f2b7e8e0eb1 in cdef_manager::initialize()
../build_source/libinterp/octave-value/ov-classdef.cc:3360
    #14 0x7f2b7ef65b69 in
octave::interpreter::interpreter(octave::application*)
../build_source/libinterp/corefcn/interpreter.cc:421
    #15 0x7f2b7e3ad5e7 in octave::application::create_interpreter()
../build_source/libinterp/octave.cc:322
    #16 0x7f2b7e3add2f in octave::cli_application::execute()
../build_source/libinterp/octave.cc:382
    #17 0x55cf2d0e1233 in main ../build_source/src/main-cli.cc:90
    #18 0x7f2b7b5142b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)


With a summary of about 180K bytes leaked. I haven't seen a bug report for
this issue so I'm submitting it. 

I have been able to narrow it down to cdef_manager::initialize() as the
problem (I reached this conclusion by commenting out the entire function).

I believe what is happening is this (from cdef_manager::initialize()
<http://hg.savannah.gnu.org/hgweb/octave/file/e250aeab3c85/libinterp/octave-value/ov-classdef.cc#l3359>
):


//other code

cdef_class tmp_meta_class
  // other code
  = make_meta_class ("meta.class", tmp_handle);

// other code
tmp_meta_class.set_class (tmp_meta_class);


When calling cdef_class.set_class() basically creates a recursive loop that
disallows tmp_meta_class.rep to be destroyed.

It has been helpful for me to look at the inheritance diagrams for cdef_object
and cdef_object_rep to not get lost in all of the different C++ classes.

This loop looks like this:
tmp_meta_class.rep == tmp_meta_class.get_class ().rep
For more explanation cdef_class::get_class() returns the property cdef_class
cdef_object_base::klass property which holds "The class of the object" (from
the source comment).
Which means that when there's only 1 tmp_meta_class.rep left the
tmp_meta_class.rep->refcount == 2. And the only way to destroy
tmp_meta_class.rep is to first destroy the cdef_object_base::klass. 










    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52123>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]