Working memory rises and rises - memory leak?

vvvv gamma bug
1

Hello.

the working memory fills up without stoping till it crashes. the important nodes are quadrenderer, foreach with keep, output-pins and sub-nodes.
I just add a demo-patch - use carefully.
important - choose an image you load in the root.
If you do not choose a path to the image - the CPU memory rises to 100% and it crashes as well.

I have testet that with version 2021.4, 2021.3.3, 2021.3.2, 2021.3.1 - it is always the same.

Need your help.

test28JUN.vl (22.6 KB)

2

One can simplify the patch even further and it still shows the memory leak.
Only thing that’s needed is a Quadrenderer inside a loop (foreach / repeat) and a Keep that is set to false.
image

Tested with 2021.4.0-0165.

Edit:
@kathi

I think you can do something like this to work around the issue:
image

3

I got rid of Keep. Perfekt.
Thank you Björn!

4

Thank you both for these patches. They expose different issues.

  1. A certain Stride script didn’t shutdown on patch shutdown causing a memory leak. For details see here
  2. In case of a nested loop the inner loop wasn’t disposed of should the outer loop have created and discarded it in the same frame. New previews have a fix for that.
  3. See https://github.com/vvvv/VL.Stride/issues/476 and https://github.com/stride3d/stride/pull/1085

Also watch out, the patch as posted by Björn doesn’t dispose the “dead” renderers. This will again lead to memory leaks. That statement was wrong - I misread the patch.

5

Mh, I let it run for some time with higher spreadcounts and didn’t see any increase in memory, so I assumed It’d be ok.
Would something like this be “correct” (just out of curiosity)?:
image

6

in general, you should only dispose of objects that will not be used anymore. in this case, the QuadRenderer is still “active” in the patch and could be used in the next frame, which would lead to an exception. because the state of the loop slice the QuadRenderer is in, is neither doposed nor re-created in the next frame.

so calling dispose on a process node is rarely a good idea, because it will only execute dispose but not remove it from the patch. so dispose is really only for objects that will not be referenced anymore after dispose was called.

7

Sorry, I think I misread your patch. Forget what I said, you patched it correctly. Essential you only ever have 4 renderers running and you simply select a few of them. It’s a very fine solution even as they never need to be re-created.

8

I updated my comment above regarding point 3) - added links to two issues I found.

9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.