bugGNU Octave - Bugs: bug #31644, Memory leaks

 
 

bug #31644: Memory leaks

Submitter:  Kai Habel <kahacjde>
Submitted:  Sat 13 Nov 2010 07:18:46 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  3 - Low Item Group:  Other
Status:  None Assigned to:  None
Originator Name:  Kai Habel 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

Sat 25 Feb 2012 08:55:00 PM UTC, comment #6: 

Closing this bug as the memory leaks reported are against a much older version of Octave.  Significant work was done to reduce memory leaks in the 3.6.X release.  Any new leaks should be reported in a new bug report against a modern version of Octave.

Rik <rik5>
Group administrator
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)

Anonymous
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.


# run with '../run-octave -f -H leak_test.m' from test directory

clear -a
for i=1:50
  fntests;
  clear -a;
  system ("ps -C lt-octave -o sz | tail -1 >> leak_test.log");
endfor

It shows a leak of approximately 196KB each time through the loop, but the leak rate is uneven.  The script and logfile are attached.

(file #22223, file #22224)

Rik <rik5>
Group administrator
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.

John W. Eaton <jwe>
Group administrator
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)

Rik <rik5>
Group administrator
Wed 17 Nov 2010 08:30:49 AM UTC, comment #1: 

I checked in the following changes and they seem to eliminate a few problems.

http://hg.savannah.gnu.org/hgweb/octave/rev/795c97ace02c
http://hg.savannah.gnu.org/hgweb/octave/rev/fe11e2b9d48a

The other "definitely lost" items did not point out anything immediately obvious to me.


John W. Eaton <jwe>
Group administrator
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

Kai Habel <kahacjde>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #22223:  leak_test.m added by rik5 (179B - application/octet-stream)
file #22224:  leak_test.log added by rik5 (300B - application/octet-stream)
file #22174:  fun.m added by rik5 (101B - application/octet-stream)
file #22175:  val.log.nofun.gz added by rik5 (17KiB - application/gzip)
file #22176:  val.log.fun.gz added by rik5 (17KiB - application/gzip)
file #22005:  LEAK.bz2 added by kahacjde (13KiB - application/x-bzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by kahacjde (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-25 rik5 Open/ClosedOpen Closed
    2010-12-18 rik5 Attached File- Added leak_test.m, #22223
        Attached File- Added leak_test.log, #22224
        Priority5 - Normal 3 - Low
    2010-12-10 rik5 Attached File- Added fun.m, #22174
        Attached File- Added val.log.nofun.gz, #22175
        Attached File- Added val.log.fun.gz, #22176
    2010-11-17 jwe SummaryMemroy leaks Memory leaks
    2010-11-13 kahacjde Attached File- Added LEAK.bz2, #22005

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code