Tue 19 Apr 2011 07:51:22 PM UTC, comment #5:
I confirm these memory leaks for 3.2.4 (debian pkg), 3.4.0 and 3.5.0 (compiled from sources with --enable-openmp).
Simply starting octave without any toolboxes any closing it
valgrind octave-3.4.0 -f --eval "1;"
reports the memory leaks (see below). Surprisingly, no memory leaks are reported with ./run-octave
valgrind ./run-octave -f --eval "1;"
Alois
$valgrind octave-3.4.0 -f --eval "1;"
==22131== Memcheck, a memory error detector
==22131== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==22131== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==22131== Command: octave-3.4.0 -f --eval 1;
==22131==
GNU Octave, version 3.4.0
Copyright (C) 2011 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'.
Octave was configured for "x86_64-unknown-linux-gnu".
Additional information about Octave is available at http://www.octave.org.
Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html
Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type `news'.
==22131==
==22131== HEAP SUMMARY:
==22131== in use at exit: 3,053,530 bytes in 7,676 blocks
==22131== total heap usage: 151,134 allocs, 143,458 frees, 18,998,786 bytes allocated
==22131==
==22131== LEAK SUMMARY:
==22131== definitely lost: 524 bytes in 27 blocks
==22131== indirectly lost: 4,676 bytes in 38 blocks
==22131== possibly lost: 1,008,271 bytes in 2,229 blocks
==22131== still reachable: 2,040,059 bytes in 5,382 blocks
==22131== suppressed: 0 bytes in 0 blocks
==22131== Rerun with --leak-check=full to see details of leaked memory
==22131==
==22131== For counts of detected and suppressed errors, rerun with: -v
==22131== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
|
Sat 18 Dec 2010 05:23:35 AM UTC, comment #4:
The memory leaks were being reported by valgrind upon exit. They aren't memory that simply wasn't freed before exit; valgrind divides leaks into various categories and that category is listed as "still reachable". The leaks I was reporting were "definitely lost". I have never, to my chagrin, found valgrind to be wrong.
On the other hand, any memory leaks do seem small and do not threaten the stability of Octave even with long run times and multiple function calls. With that in mind, I'm lowering the priority of this issue to Low and it can be taken up again after the 3.4 release.
I was able to provoke a memory leak, however I haven't localized it to any particular feature -- that work can come later. I used the following script in the test directory.
|
Sun 12 Dec 2010 06:15:41 AM UTC, comment #3:
Do these messages only appear when you exit? Is this happening because Octave is not explicitly freeing some memory before it exits?
If there is a leak in parsing and evaluating this function, then I would expect
while (1) try fun; end; clear fun; end;
to cause Octave's memory usage to constantly grow, but I don't see that when I watch the process with top. I would also expect valgrind to tell me that more memory is lost the longer I run the loop, but that doesn't seem to be happening either.
I'm not sure these leaks are something we need to worry about, but if you can find something that leaks when run in a loop and that makes the Octave process measurably grow and not just generate messages from valgrind when Octave exits, then I'll try to take a look at it.
|
Fri 10 Dec 2010 11:25:55 PM UTC, comment #2:
There is a memory leak in the parser which evaluates functions. Simple test code, fun.m, is attached which provokes the leak. I compiled octave with CFLAGS=-g -O0 to avoid optimizing out variables and fully see where leaks are occurring. The logfile on cleaning up from subfunctions which terminate with an error. val.log.nofun.gz was created by running octave and immediately exiting. The recorded record of "definitely lost" bytes is a baseline. The second log, "val.log.fun.gz", was created by running octave, running the function fun once, and then exiting.
(file #22174, file #22175, file #22176)
|
Sat 13 Nov 2010 07:18:46 PM UTC, original submission:
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
|