bugGNU Octave - Bugs: bug #31644, Memory leaks

 
 

bug #31644: Memory leaks

Submitted by:  Kai Habel <kahacjde>
Submitted on:  Sat 13 Nov 2010 07:18:46 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 3 - LowItem Group: Other
Status: NoneAssigned to: None
Originator Name: Kai HabelOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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.

Rik <rik5>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member

 

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

Attach File(s):
   
   
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
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by kahacjde (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 25 Feb 2012 08:55:00 PM UTCrik5Open/ClosedOpen=>Closed
    Sat 18 Dec 2010 05:23:35 AM UTCrik5Attached File-=>Added leak_test.m, #22223
      Attached File-=>Added leak_test.log, #22224
      Priority5 - Normal=>3 - Low
    Fri 10 Dec 2010 11:25:55 PM UTCrik5Attached File-=>Added fun.m, #22174
      Attached File-=>Added val.log.nofun.gz, #22175
      Attached File-=>Added val.log.fun.gz, #22176
    Wed 17 Nov 2010 08:31:13 AM UTCjweSummaryMemroy leaks=>Memory leaks
    Sat 13 Nov 2010 07:18:46 PM UTCkahacjdeAttached File-=>Added LEAK.bz2, #22005

    Back to the top


    Powered by Savane 3.1-cleanup1