bugGNU Octave - Bugs: bug #44420, Memory leaks in 4.0 RC

 
 

bug #44420: Memory leaks in 4.0 RC

Submitted by:  Rik <rik5>
Submitted on:  Wed 04 Mar 2015 04:51:43 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Performance
Status: NoneAssigned to: None
Originator Name: Open/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)

Fri 01 Sep 2017 07:30:34 PM UTC, comment #9:

Closing report. This bug was reported against the 4.0 RC which is now very out of date. The Octave developers have also switched to ASAN for a lightweight memory checker rather than valgrind.

Rik <rik5>
Project Administrator
Sat 02 Jul 2016 07:00:52 AM UTC, comment #8:

I've looked around a bit more and I think I understand things a little better. Sorry for the noise. I found the comment in toplev.cc about "Don't call singleton_cleanup_list ..." and uncommented the cleanup call and
commented the typeinfo cleanup call:
Now "cdef_manager::cleanup_instance()" gets called.

Robert Jenssen <morgawr>
Fri 01 Jul 2016 01:16:41 AM UTC, comment #7:

I built a debug build of the development sources with:
+verbatim
diff -r f471f513ffd0 libinterp/corefcn/Cell.h
--- a/libinterp/corefcn/Cell.h Wed Jun 29 18:50:37 2016 -0400
+++ b/libinterp/corefcn/Cell.h Fri Jul 01 11:00:59 2016 +1000
@@ -41,7 +41,7 @@
public:

Cell (void)
- : Array<octave_value> (dim_vector (0, 0)) { }
+ : Array<octave_value> () { }

Cell (const octave_value& val)
: Array<octave_value> (dim_vector (1, 1), val) { }
-verbatim-
It passes "make check".

Most of the remaining leaks also appear to be due to reference counting in dim_vector and ArrayRep. For example valgrind shows:
and

Robert Jenssen <morgawr>
Sat 21 Mar 2015 02:17:08 AM UTC, comment #6:

Using the valgrind log I can see that a whole slew of small 8 byte leaks are due to this code in ov-classdef.cc at line 701.

Everywhere an empty Cell() object is created causes a leak.

I believe the put routine is defined at ov-classdef.h:408.

Maybe when a map goes out of existence it is somehow failing to call the the destructor for the right-side value.

Rik <rik5>
Project Administrator
Wed 04 Mar 2015 05:14:26 PM UTC, comment #5:

I'm using valgrind 3.7.0.

A simpler, quicker test is

assuming that run-octave has been hacked to run octave-cli. This completes in about 1 minute and shows leaks from classdef.

Rik <rik5>
Project Administrator
Wed 04 Mar 2015 04:52:49 PM UTC, comment #4:

OK, I'm now trying exactly the same options as you used, except for the log file because I want to see the valgrind messages mixed with the list of tests.

What version of valgrind are you using?

John W. Eaton <jwe>
Project Administrator
Wed 04 Mar 2015 04:11:57 PM UTC, comment #3:

I ran into that same problem of running valgrind on the dispatch program octave rather than on octave-cli or octave-gui. I worked around it by editing my copy of run-octave.

Rik <rik5>
Project Administrator
Wed 04 Mar 2015 03:32:49 PM UTC, comment #2:

Oops, wait, I think the way I was running make check made it so that I was only running valgrind on the driver program, not Octave itself.

Trying again by forcing octave-cli in the run-octave script. Now the tests are running much slower, so I think I'm using valgrind now. But so far no messages either. I'll let it run and see what happens.

I guess we need a way to be able to specify both -valgrind and -cli as options for the run-octve script...

John W. Eaton <jwe>
Project Administrator
Wed 04 Mar 2015 03:27:33 PM UTC, comment #1:

I'm not seeing results that are so bad.

I tried running

When that was silent where you had errors, I edited the run-octave script to add --leak-check=full to the valgrind options and tried again. I still don't see the errors you are seeing.

What version of valgrind do you have? I'm using 1:3.10.0-4 on a Debian amd64 system.

John W. Eaton <jwe>
Project Administrator
Wed 04 Mar 2015 04:51:43 AM UTC, original submission:

See the attached file which is the output from using hg id 19894:ac18e88ea1bf under valgrind and running _run_test_suite_.

Search for "definitely lost" to find guaranteed memory leaks.

There are definitely some in the new classdef parser.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #33242:  valgrind.log.bz2 added by rik5 (161KiB - application/x-bzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by morgawr (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by rik5 (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 01 Sep 2017 07:30:34 PM UTCrik5Open/ClosedOpen=>Closed
    Wed 04 Mar 2015 04:51:43 AM UTCrik5Attached File-=>Added valgrind.log.bz2, #33242

    Back to the top


    Powered by Savane 3.1-cleanup1