bugGNU Octave - Bugs: bug #60979, Memory space used per GNU octave...

 
 

bug #60979: Memory space used per GNU octave increases inexplicably

Submitted by:  Simon Morisset <simon_morisset>
Submitted on:  Tue 27 Jul 2021 02:34:13 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Works For Me Assigned to:  None
Originator Name:  Simon Morisset Open/Closed:  Open
Release:  6.3.0 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Wed 25 Aug 2021 01:26:51 PM UTC, comment #5: 

No one seems to be able to reproduce the memory leak reported in comment #0 with the information provided so far.

The issue might be with the `udp` class in the "instrument-control" package. (Does the `refreshdata` call cause a read from an udp object?)

@Simon: Could you provide a self contained example that can be used to reproduce the issue?

Markus Mützel <mmuetzel>
Project Member
Fri 30 Jul 2021 05:06:09 PM UTC, comment #4: 

adding a datapoint to the others.

running Windows 10, Octave 6.3.0 gui or CLI, neither shows this problem.

both start with base memory of 22-50MB (cli vs gui), then running the first example, both increase as they open a figure, etc., to 53 & 80MB.  they then hold steady however long I keep them running.

this is with the default qt toolkit.

rerunning with graphics_toolkit('fltk') and graphics_toolkit('gnuplot'), same behavior (but memory only jumps by ~1MB each)

@simon_morisset, recommend confirming Octave version and graphics toolkit and whether you are still seeing the issue.

Nicholas Jankowski <nrjank>
Project Member
Wed 28 Jul 2021 11:24:58 PM UTC, comment #3: 

Unable to reproduce a memory leak on Linux with both tests. Might be Windows-specific alone?

@OP (Simon), some questions for you:

1. Your Octave versions are listed as "6.0.1 and 6.0.3". Should that be 6.1.0 and 6.3.0 or did you find these versions from a non-release location somewhere?

2. How much RAM do you have and how many GB had Octave used up at the freezing point? How many hours does that take? If we can get an estimate of how many MB per hour are leaking at your end (and we haven't found a leak yet), we can wait an appropriately scaled time if we have a different amount of RAM to see the leak.

3. This hack may help you in general, which I learned from my Matlab-using days on Windows. If you create a suitably large array like perms(1:10) or perms(1:11), and then clear it, you'll find that a lot more memory becomes available to Octave (or Matlab for that matter). It's something to do with Windows caching a lot of memory for programs that have been running for a long time, and sometimes that needs to be flushed by allocating and deallocating a big chunk of memory. Let us know if this works for you.

Anonymous
Tue 27 Jul 2021 09:21:11 PM UTC, comment #2: 

As an additional data point, the first example code works fine for me (no memory leak) with version 6.3 and the development branch on a Linux machine.

Rik <rik5>
Project Administrator
Tue 27 Jul 2021 04:25:32 PM UTC, comment #1: 

I can't reproduce with your example #1 on Windows 10 with Octave 6.3.0 (no packages loaded).

I also cannot reproduce with your example #2 (after `pkg load instrument-control`).

Reproducing the code so that other can more easily cut and paste:

% Example #1
fig = figure;
while 1
  refreshdata(fig)
  pause(0.1)
end


% Example #2
s=udp('10.0.0.16', 10001,'localport',10000); % with incoming data in this port
while 1
  fread(s,s.bytesavailable);
  pause(0.1)
end
udp_close(s);

Markus Mützel <mmuetzel>
Project Member
Tue 27 Jul 2021 02:34:13 PM UTC, original submission:  

I run scripts which read data from an udp port and then make several figures in real time every seconds. The code works very well. However, the memory space used per Octave when these scripts are running, increase continusly while the size of the variables remains unchanged. I isolated two small examples which reproduce this increasing of memory space (looking memory from windows in task manager):

% Example #1
-- fig = figure;
-- while 1
--         refreshdata(fig)
--         pause(0.1)
-- end

% Example #2
-- s=udp('10.0.0.16', 10001,'localport',10000); % with incoming data in this port
-- while 1
--         fread(s,s.bytesavailable);
--         pause(0.1)
-- end
-- udp_close(s);

When one of these two example is running, the memory increases step by step. If I let these codes running several hours or days, they saturate the windows memory and Octave freezes.

If I stop these codes before freezing and I clear all the Octave space (clear all, clear classes, clear java, clc), the memory does not reduce. The only solution is to restart Octave to comeback to a normal memory level (~50Mo)

First question: Why the memory increases when no variables are increasing?
Second question: How to flush the full octave memory without restart it?

Thank you for the support.
Regards

Windows 10
Ocatve 6.0.1 and 6.0.3

Simon Morisset <simon_morisset>

 

(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 (Updated the item)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by simon_morisset (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-20 jwe CategoryNone => Interpreter
    2021-07-29 rik5 Carbon-CopyRemoved 72865 => -
    2021-07-29 rik5 StatusNone => Works For Me
    2021-07-27 rik5 Carbon-CopyRemoved 72865 => -

    Back to the top


    Powered by Savane 3.6