[Octave-bug-tracker] [bug #31644] Memroy leaks

[Kai Habel]

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

                 Summary: Memroy leaks
                 Project: GNU Octave
            Submitted by: kahacjde
            Submitted on: Sat 13 Nov 2010 08:18:46 PM CET
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Other
                  Status: None
             Assigned to: None
         Originator Name: Kai Habel
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

While debugging some problems with uimenu using valgrind, I noticed some
memory leaks in octave. To do this I have modified the run-octave script
(~line 58) in order to have a full-check.

driver="valgrind --tool=memcheck --leak-check=full"

If I run octave with:

./run-octave -valgrind 2> LEAK

run the surfl demo and exit:

demo surf

I get the attached log file LEAK.bz2

The summary is as follows:

==3192== LEAK SUMMARY:
==3192==    definitely lost: 14,521 bytes in 163 blocks
==3192==    indirectly lost: 109,605 bytes in 430 blocks
==3192==      possibly lost: 1,360,977 bytes in 5,277 blocks
==3192==    still reachable: 36,671,196 bytes in 8,948 blocks
==3192==         suppressed: 0 bytes in 0 blocks

I think the problems are the definitively lost blocks.

Like:

==3192== 8 bytes in 1 blocks are definitely lost in loss record 31 of 1,109
==3192==    at 0x4C262E6: operator new[](unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3192==    by 0x5488EEF: octave_cell::register_type() (oct-mem.h:131)
==3192==    by 0x556EF2D: install_types() (ov.cc:2632)
==3192==    by 0x539B93E: octave_main (octave.cc:632)
==3192==    by 0xB866B7C: (below main) (in /lib64/libc-2.11.2.so)


and 


=3192== 8 bytes in 1 blocks are definitely lost in loss record 32 of 1,109
==3192==    at 0x4C262E6: operator new[](unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3192==    by 0x52A5DBF: std::string* no_ctor_new<std::string>(unsigned
long) (oct-mem.h:131)
==3192==    by 0x62DA26D: Array<std::string>::Array(dim_vector const&)
(Array.h:80)
==3192==    by 0x62DC6DA: Array<std::string>::resize(int, int, std::string
const&) (Array.cc:973)
==3192==    by 0x529F628: load_path::dir_info::get_file_list(std::string
const&) (str-vec.h:90)
==3192==    by 0x529FA32: load_path::dir_info::initialize()
(load-path.cc:125)
==3192==    by 0x52A81E0: load_path::dir_info::dir_info(std::string const&)
(load-path.h:279)
==3192==    by 0x52A3A2F: load_path::do_add(std::string const&, bool, bool)
(load-path.cc:632)
==3192==    by 0x52A4526: load_path::do_set(std::string const&, bool)
(load-path.cc:592)
==3192==    by 0x52A5090: load_path::do_initialize(bool) (load-path.cc:516)
==3192==    by 0x539C5A4: octave_main (load-path.h:53)
==3192==    by 0xB866B7C: (below main) (in /lib64/libc-2.11.2.so)


I have not looked at the source files itself and I am not even sure the
valgrind output points to real problems. In that case just close this report.

Kai



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sat 13 Nov 2010 08:18:46 PM CET  Name: LEAK.bz2  Size: 13kB   By:
kahacjde

<http://savannah.gnu.org/bugs/download.php?file_id=22005>

    _______________________________________________________

Reply to this item at:

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

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