[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #31644] Memory leaks
From: |
Rik |
Subject: |
[Octave-bug-tracker] [bug #31644] Memory leaks |
Date: |
Sat, 18 Dec 2010 05:23:35 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/9.10 (karmic) Firefox/3.6.13 |
Update of bug #31644 (project octave):
Priority: 5 - Normal => 3 - Low
_______________________________________________________
Follow-up 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)
_______________________________________________________
Additional Item Attachment:
File name: leak_test.m Size:0 KB
File name: leak_test.log Size:0 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31644>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/