Finding Memleaks

vvvv beta question
1

Hello

I’m trying to find a memoryleak in a big project.
Is there a way of displaying how much memory each individual node takes up?

Something like Ctrl F9, which shows CPU usage per node, for memory usage.

I know it’s not going to be unambiguous - who’s ‘memory’ is it when two nodes store the same object? Also hard - how do you figure out who’s storing what?

Or any other method of hunting down memleaks?

Thanks!

2

Not sure if this is getting you anywhere, since you might break dependencies on your way that might have caused the leak … but maybe:

Start from the root of your project and delete a subpatch, then another, and so on. Check your vvvv.exe process memory usage at all times while doing so, until you may eventually see a large chunk of memory being released. If you found something, proceed one level further in terms of subpatches and repeat.

I presume that objects are getting disposed as soon as their responsible node is deleted from the patch.

Let me know if this works, I’m curious as well.

3

You could also go through and set sub patches to evaluate= 0 and see if the memory keeps increasing, or is it on specific actions that it happens?

4

witch vvvv version 64 or 32? how the patch looks like? Heavy geometry or tons of textures? Why would you look for leak? i think if you describe what’s happening would be easier to find it.

5

I was asking from a general perspective, how to tackle memory leaks in vvvv. A specific case caught my interest, it was in a friends project though - quite large patch, both heavy on gpu and cpu, tons of textures. Not easy to spot. Crashed after running for five days, out of memory. 64bit.

But really the question is about your thoughts on how to tackle memory leaks in general, and what the kind of questions are you’d ask to debug.

You could also go through and set sub patches to evaluate= 0 and see if the memory keeps increasing, or is it on specific actions that it happens?

That’s the only real solution I was able to think of. There are two problems with it:

  1. slow. If, like in our case, the memory increases very slowly, it will be hard to catch.
  2. Not evaluating one patch might influence other patches and change behaviour

But I guess that’s the best option so far - probably better than deleting subpatches, but similar in concept.

There should be some kind of analysis tool, I guess…
If anybody has other hints, they’re very welcome.

1 Like
6

I don’t think there is a general way of finding mem leaks…
I would look for resources aren’t released when you switch textures models etc…

7

Have you tried turning undo off? I used to have crashes with a patch for installations, we were using set patch to change fx, but similarly, if your setting values in ioboxes, or similar, that can add to the undo buffer, and eventually it will run out of memory. If that is the cases, the undo node has an enable pin, for exactly that purpose ;)

8

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