It seems the destructor for CVEX_Context doesn't completely clean up.

This causes memory usage to grow like crazy:


for (int idx = 0; idx < num_shaders; idx++)
{
CVEX_Context cvex;

// … set up inputs

if (cvex.load(argc, argv))
{
cvex.run(data_size, false);
}

// … do something with outputs
}


While this does not:


CVEX_Context cvex;
for (int idx = 0; idx < num_shaders; idx++)
{
// … set up inputs

if (cvex.load(argc, argv))
{
cvex.run(data_size, false);
}

// … do something with outputs

cvex.clear();
}


I didn't notice until this block of code was being run tens of thousands of times, so it's not a huge leak.

mark_visser
It seems the destructor for CVEX_Context doesn't completely clean up.

This causes memory usage to grow like crazy:


for (int idx = 0; idx < num_shaders; idx++)
{
CVEX_Context cvex;

// … set up inputs

if (cvex.load(argc, argv))
{
cvex.run(data_size, false);
}

// … do something with outputs
}


While this does not:


CVEX_Context cvex;
for (int idx = 0; idx < num_shaders; idx++)
{
// … set up inputs

if (cvex.load(argc, argv))
{
cvex.run(data_size, false);
}

// … do something with outputs

cvex.clear();
}


Hmmm… I'd have to see more of what's going on… The destructor of the CVEX_Context calls clear, so I don't see too much of a difference between the samples.

mark
Hmmm… I'd have to see more of what's going on… The destructor of the CVEX_Context calls clear, so I don't see too much of a difference between the samples.

You're right, mistake on my part.

It's very strange – it only happens when CVEX is run from inside a procedural. When the exact same code is called from a SOP, it doesn't leak.

I'm not 100% convinced it's a leak either. I just ran it through valgrind and it didn't report it. Could it be something global that CVEX is allocating that doesn't get freed until mantra finishes?

cheers,
-Mark

Found it… bad bounding boxes were forcing mantra to keep geometry in memory until the end of the render. Sorry for the false alarm. ops: