bugGNU Octave - Bugs: bug #53514, Memory leaks in 4.4 release

 
 

bug #53514: Memory leaks in 4.4 release

Submitted by:  Rik <rik5>
Submitted on:  Thu 29 Mar 2018 05:11:24 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  3 - Low Item Group:  Other
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

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)

Mon 03 Sep 2018 01:59:43 AM UTC, comment #17:

Closing report. The next memory leak tests will occur before the 5.0 release.

Rik <rik5>
Project Administrator
Tue 03 Apr 2018 11:13:18 PM UTC, comment #16:

Marking bug as postponed. The 56B leak is not a showstopper for the 4.4 release.

Rik <rik5>
Project Administrator
Mon 02 Apr 2018 03:34:24 AM UTC, comment #15:

Is there a way to test for memory leaks over a sustained period of time? I tried using _run_test_suite_ in a for loop and periodically checking the memory usage of the process with ps. Unfortunately that did show ever increasing memory usage, but that could be real because of the use of setenv.

Rik <rik5>
Project Administrator
Fri 30 Mar 2018 11:10:16 PM UTC, comment #14:

I think these small leaks can be left until after the 4.4 release.

John W. Eaton <jwe>
Project Administrator
Fri 30 Mar 2018 05:32:36 AM UTC, comment #13:

Of course, there is also this comment near register_type

Rik <rik5>
Project Administrator
Fri 30 Mar 2018 05:28:22 AM UTC, comment #12:

It seems that it maybe the type_info class needs a destructor which unregisters all the registered types.

The backtrace for one of the 8 byte leaks is

interpreter.cc:369 is the constructor for an interpreter object. One of the data members is m_type_info().

The constructor for type_info is next at ov-typeinfo.cc:80 which calls

install_types is in ov.cc and has 55 register_type calls

If you look at ov-typeinfo.h you find that there is no destructor.

So, I think what has to happen is that a destructor gets written to call delete for each of the types.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 11:23:42 PM UTC, comment #11:

Yes, that new is not paired with a delete and it should be. But I've looked at this recently and it's still not clear to me when that can happen. I probably could have saved you some time if I'd left a comment there. Sorry.

John W. Eaton <jwe>
Project Administrator
Thu 29 Mar 2018 08:30:43 PM UTC, comment #10:

I was able to run through the entire test suite. I'm attaching the list of "Direct leak"s. It seems that a fair number are related to octave_putenv which cannot be changed. 56 other instances are related to register_type as I noted in the first submission. And then there are a few odd leaks that appear to be related to feval. I don't know if there is a problem with feval, or whether the code that was executed had a leak.

For the 56 instances of register_type, I think there should be a simple solution. This is code from ov-base.h

It looks to me like that call to new is not paired with a delete.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 06:57:19 PM UTC, comment #9:

It was just what I thought. Moving the initialization of variables inside the for loop fixes the problem because the array x is never accessed when it is empty. See this cset: http://hg.savannah.gnu.org/hgweb/octave/rev/576ff914979c.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 06:39:39 PM UTC, comment #8:

I'm getting a heap-buffer-overflow in _expint_.cc when running the tests for cosint.m. Adding Michele Ginesi to the CC list for this bug since he wrote that code. The abbreviated backtrace from gdb is:

Looking at the code around line 134 in _expint_.cc I see this:

My guess is that the code is not properly handling the case where the matrix is empty, i.e., numel == 0. In that case, we shouldn't be indexing in to the array to get x(0).

The loop below it is

Given that the first thing the body of the loop does is to initialize all of these values, it might be better to eliminate the initialization outside the loop.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 06:04:40 PM UTC, comment #7:

I just configured with '--disable-java' and I no longer get a segfault. I'm going to leave Java for later. I'm running 'make check' right now to see if there are any leaks over the entire test suite.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 05:56:13 PM UTC, comment #6:

I get this:

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Mar 2018 05:45:23 PM UTC, comment #5:

I don't get any print out at all when I have leak_check_at_exit=0. It just runs and exits.

I have -O0 and -ggdb3 in my CFLAGS now, but the backtrace for the segfault in ov-class.cc is still uninformative.

I think this may have something to do with the Java JDK because I get a message in gdb about "Installing openjdk unwinder". Also, "test ov-java.cc" segfaults in the same way. I am going to disable java in the build and see what happens.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 05:33:56 PM UTC, comment #4:

I have to setup this option otherwise the configure step fails at ARPACK detection.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Mar 2018 05:20:34 PM UTC, comment #3:

@Dmitri: I will try with leak_check_at_exit=0 in about 30 minutes when I have a new build.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 05:16:36 PM UTC, comment #2:

Also, something in ov-class.cc is causing a segfault. I will have to re-compile with debugging enabled to get a backtrace, but for now I have

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 05:15:22 PM UTC, comment #1:

Do you get those if you set leak_check_at_exit=0 ?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Mar 2018 05:11:24 PM UTC, original submission:

I configured with --enable-address-sanitizer-flags and then ran

There is a leak of 8 bytes which is repeated 56 times (approximately the number of octave value types?). All of the leak records look about like this one:

Rik <rik5>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

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

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-03 rik5 Open/ClosedOpen => Closed
    2018-04-03 rik5 Priority5 - Normal => 3 - Low
        StatusIn Progress => Postponed
    2018-03-29 rik5 Carbon-Copy- => Added jwe
    2018-03-29 rik5 StatusNone => In Progress
    2018-03-29 rik5 Carbon-Copy- => Added m_ginesi

    Back to the top


    Powered by Savane 3.3