bugGNU Octave - Bugs: bug #55064, Updating graphics object consumes...

 
 

bug #55064: Updating graphics object consumes memory

Submitter:  None
Submitted:  Tue 20 Nov 2018 03:53:23 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Duplicate Assigned to:  None
Originator Name:  Robert F Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.4.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 Jan 2019 01:47:15 AM UTC, comment #10: 

That's great Rik! Your change checks out on my system when implemented on a new pull. I have so many of these types of animations to run during my lecture, it's going to be nice to be able to leave it running and not worry about eating up swap and crashing. Good work!

Robert F <robcylon7>
Thu 17 Jan 2019 11:51:28 PM UTC, comment #9: 

I just posted a sketch of a change which fixes the issue at bug #55287.  With the fix in place I re-ran the solarsystem example on this report and it was also fixed.

Hence, these really are the same bug and I am going to close this one and continue the resolution efforts on #55287.

Rik <rik5>
Group administrator
Tue 08 Jan 2019 06:14:59 PM UTC, comment #8: 

I now see the effort put forth over at https://savannah.gnu.org/bugs/?55287, I'll follow that thread.

Robert F <robcylon7>
Tue 08 Jan 2019 04:38:47 PM UTC, comment #7: 

Some more testing on my original script. I've found that the issue is NOT fixed by

1) using $cla reset; (or $cla;); which also means I have to re-plot as well as set axis properties again,
2) using $delete(get(gca,'children')); which means I only need to re-plot, but keep axis configurations.

However, the least intrusive way I've found to avoid the memory issue is in an obviously inefficient (very slow rendering) $delete(gca); needing to also set all axis options again.

Robert F <robcylon7>
Tue 08 Jan 2019 05:50:54 AM UTC, comment #6: 

I did run this test with ASAN and I do not see any difference in
reported leaked bytes ( SUMMARY: AddressSanitizer: 154727 byte(s) leaked in 2686 allocation(s)) no matter how long I wait.
(I do see memory used is increasing, as reported by top)

This is with 72e0a106d956 (stable) tip

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Thu 13 Dec 2018 05:35:33 PM UTC, comment #5: 

bug #55052 looks suspiciously related.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 12 Dec 2018 04:38:35 PM UTC, comment #4: 

Thanks, just to confirm, the same behavior appears in 4.2.2, and even cla and clf don't get around the issue.

Robert F <robcylon7>
Tue 20 Nov 2018 11:31:37 PM UTC, comment #3: 

I have broken the original archive file in to four pieces: 55064.[a-d].tar.lz and uploaded them.  To recreate the original file and then unpack it use


cat 55064.*.tar.lz > tmp.tar.lz
lzip -d tmp.tar.lz
tar xf tmp.tar


Then


cd solarsystem/script
octave
solarsystem3



Rik <rik5>
Group administrator
Tue 20 Nov 2018 11:27:12 PM UTC, comment #2: 

The Savannah bug tracker has an annoyingly low file limit.  I downloaded your test case from Google Drive.  I had to modify the paths in solarsystem3.m to point to the data/ directory, but then it ran fine.

There is something wrong.  I let it run for a while and memory consumption on the process rose from 2GB to 6GB.  After breaking out of the loop with Ctrl-C I closed the figure and deleted all variables, but the Octave process continued to use a bunch of memory. 

Marking as confirmed.

Rik <rik5>
Group administrator
Tue 20 Nov 2018 04:16:04 PM UTC, comment #1: 

not quite sure qhy the file didn't upload but
https://drive.google.com/open?id=1G9PNuYKVZmZkVoMQ8XGEFd35vDA4OLjK

Robert F <robcylon7>
Tue 20 Nov 2018 03:53:23 PM UTC, original submission:  

I don't think this is the intended behavior of 'set(h,'xdata'...)' and I can't figure out a way to update a plot, with identically sized 'data' arrays, without octave searching for more memory with each update.

Either using the 'set' or even 'delete(h); clear('h'), h=plot3();', when I update the plot with a new set of data that is exactly the same dimensions, new memory is reserved. This creates a huge problem where, in the simplified script I have attached, octave's reserved memory goes from ~200MB to many GB's very quickly. Is this the intended behavior of 'set' or is there a better way that can be documented (or maybe I missed?) to update a plot? Regards, Robert.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45503:  55064.d.tar.lz added by rik5 (581KiB - application/octet-stream)
file #45502:  55064.c.tar.lz added by rik5 (750KiB - application/octet-stream)
file #45501:  55064.b.tar.lz added by rik5 (750KiB - application/octet-stream)
file #45500:  55064.a.tar.lz added by rik5 (750KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-17 rik5 StatusConfirmed Duplicate
        Open/ClosedOpen Closed
    2018-12-27 rik5 Dependencies- bugs #55287 is dependent
    2018-11-20 rik5 Attached File- Added 55064.d.tar.lz, #45503
    2018-11-20 rik5 Attached File- Added 55064.c.tar.lz, #45502
    2018-11-20 rik5 Attached File- Added 55064.b.tar.lz, #45501
    2018-11-20 rik5 Attached File- Added 55064.a.tar.lz, #45500
    2018-11-20 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code