bugGNU Octave - Bugs: bug #40233, Memory leak in oct-shlib

 
 

bug #40233: Memory leak in oct-shlib

Submitted by:  Rik <rik5>
Submitted on:  Thu 10 Oct 2013 03:47:31 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: InvalidAssigned 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.

 

Wed 16 Oct 2013 03:02:31 PM UTC, comment #3:

I can't see that Octave is doing anything wrong when it opens shared libraries, so I think this leak is outside of our code. Closing report.

Rik <rik5>
Project Administrator
Fri 11 Oct 2013 05:38:17 PM UTC, comment #2:

I agree that this isn't a threat to the stability of Octave. However, I wouldn't close the report because there is definitely something going on. The example I listed lost only 56 bytes which is inconsequential. However over a full run of the test suite, 4096 bytes were lost. Although the growth is very slow, it doesn't appear that there is a cap.

Enough changes have taken place that the whole test suite needs to be re-run under valgrind (and I know you are doing that from a different bug report). Perhaps this has been fixed. If not, I would try running the test suite and executing a 'clear -all' at the end to see if this is only valgrind not recognizing objects that would be cleaned up in the course of normal events.

Rik <rik5>
Project Administrator
Thu 10 Oct 2013 08:57:43 PM UTC, comment #1:

I haven't investigated, but I suspect that this is another case of allocating resources and not explicitly cleaning them up before Octave exits.

If this is due to loading .oct files, then I'm only concerned about it if Octave is not properly freeing memory if you do something like repeatedly call a function defined in a .oct file, then clear it. If that causes Octave to grow without bound, then there is an actual leak we should worry about.

If I do

Octave does not appear to grow. I can verify with lsof that qr.oct is loaded when I call it and closed when I clear it.

So maybe we should close this report?

John W. Eaton <jwe>
Project Administrator
Thu 10 Oct 2013 03:47:31 AM UTC, original submission:

The leak is in the shared library code oct-shlib. Perhaps helpful, or perhaps a red herring, it is a PKG_ADD command that starts the leak sequence.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -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
    Wed 16 Oct 2013 03:02:31 PM UTCrik5StatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1