window.snapshot() memory leak?

[nmnaughton]

I am new to fury and am trying to use it to make a video of streamlines that are changing in time. To do this I am saving a .png for every frame and then later stitching them together using ffmpeg.

When I save the images by looping through streamlines for each timestep, it seems like fury does not release the memory associated with saved images. This leads to memory accumulation as the loop runs, eventually crashing my computer.

Not sure if this is expected behavior or a bug. If expected behavior, how can I free the memory so I can run the loop for an arbitrary number of iterations?

The MWE code below ends up using ~7 Gb of memory by the time it finishes and the memory usage is proportional to the value of the time loop. This behavior occurs for both window.snapshot() and window.record().

from fury import window, actor
import numpy as np

t = np.linspace(-10, 10, 100)
bundle = []
for i in np.linspace(3, 5, 1000):
    pts = np.vstack((np.cos(2 * t/np.pi), np.zeros(t.shape) + i*10, t )).T
    bundle.append(pts)

ren = window.Scene()
for time in range(200):#len(plot_params["rod0"]["time"])):
    ren.clear()
    bundle_actor = actor.streamtube(bundle, window.colors.red, linewidth=0.01)
    ren.add(bundle_actor)
    ren.SetBackground(*window.colors.white)
    image_array = window.snapshot(
        ren, fname='tmp/file%02d.png' % time, size=(1000, 1000))

Thanks!

[skoudoro]

Hi @nmnaughton,

Thank you for this nice report and your example. We will look into it and let you know as soon as possible.

Can you give us your FURY version?

We know that a list of Numpy array creates a memory leak. This is why we created the ArraySequence object on Nibabel package or the sister Streamlines object on DIPY.

So it could be the main reason for your problem but we need to check to be sure.

[nmnaughton]

Thanks for your help on this.

I am using version 0.4.0

I get similar behavior if I use bundle = dipy.tracking.streamline.Streamlines() instead of bundle = [] so I am not sure if that is it.

Also, the memory size is substantially larger than 200x the size of my streamline data or the size of the saved images (18 MB total), so it seems some intermediary state is accumulating the memory.

My current work around is to just manually run the loop in batches with a small enough loop size that the memory size doesn't get too large. I could also probably write a work around where I run the batches with a child process, which should then release the memory, but neither are very fast or scalable options.

[Garyfallidis]

And what VTK version. fury.get_info() should provide that information.

[nmnaughton]

8.1.2.

Here is the whole output

>>> fury.get_info()
{'fury_version': '0.4.0', 'pkg_path': '/usr/local/lib/python3.7/site-packages/fury', 
'commit_hash': 'd9bff9ebbb15fee7773845d0b0866870857b17bb', 
'sys_version': '3.7.6 (default, Dec 30 2019, 19:38:26) \n[Clang 11.0.0 (clang-1100.0.33.16)]', 
'sys_executable': '/usr/local/opt/python/bin/python3.7', 'sys_platform': 'darwin', 
'numpy_version': '1.18.1', 'scipy_version': '1.4.1', 'vtk_version': '8.1.2', 
'matplotlib_version': '3.1.3', 'dipy_version': '1.1.1'}

[skoudoro]

Sorry for getting back late to you.

I confirm the memory leak and we will try to fix it before the release this week.

Again, thank you for the feedback!

[Nibba2018]

It looks like an interesting issue. How do you approach such memory leaks?

[anushka17agarwal]

Can I try to work on this issue if it's still available to work on?

[skoudoro]

this is an old issue, but it seems that VTK is working on it to fix the memory leak on the RenderWindow.

The workaround is to create a snapshot inside the Showmanager class directly to avoid looping with Renderwindow. I need to create a PR sometime, next week.

to keep track of the evolution of Renderwindow:

ref: https://discourse.vtk.org/t/vtkrenderwindow-memory-leak/10612