memory leak

[nvidia]

memory leak

[ramakarl]

This should work.
Would be interesting to determine the root cause.

[oursnoir]

Hmm, is there any destructor in the VolumeGVDB class that deallocate the following members (allocated in VolumeGVDB::Initialize)?

• mCudpp (CPU and GPU leak ?)
• mPlan_max (CPU and GPU leak ?)
• mPlan_min (CPU and GPU leak ?)
• mScene (CPU leak ?)
• mPool (CPU and GPU leak ?)
• cuVDBInfo (GPU leak only)
• mTransferPtr (GPU leak only)

These are the ones for which I can't find any deallocation code and that I can (without a 100% certainty) relate to the trace given by a cuda-memcheck --leak-check full invocation.

Additionnaly there is no member method of VolumeGVDB that release the memory allocated by mPool.

I have to do something like (not sure what is absolutely necessary or not though):

gvdb->DestroyChannels();
gvdb->CleanAux();
gvdb->mPool->PoolReleaseAll();
gvdb->Clear();

But it doesn't solve the leak from the above-mentioned members.

[NBickford-NV]

Hi all,

I finally implemented destructors for most of the main GVDB classes in cpmmits dc4d3a0 and f0d05bb.

This makes it so that
while (1) { nvdb::VolumeGVDB gvdb; gvdb.SetCudaDevice(GVDB_DEV_CURRENT); gvdb.Initialize(); }
should run without leaking memory (testing in gRenderKernel, the amount of memory used appears to be constant). Note that it's important to use GVDB_DEV_CURRENT when creating and destroying GVDB objects in a loop like this - otherwise, each GVDB instance will create a new CUDA context just for that instance, and since GVDB allows user code to pick up on the generated CUDA context, will keep the context around (and consequently accumulate CUDA contexts if run in a loop)!
while (1) { nvdb::VolumeGVDB gvdb; gvdb.SetCudaDevice(GVDB_DEV_FIRST); gvdb.Initialize(); }

In addition, cuda-memcheck --leak-check full should now run cleanly (with the exception of a CUDA/OpenGL interop error) on the three non-interactive samples.

Please let me know if this significantly breaks things, since it also slightly changes the semantics of setting the scene's camera and light objects (these functions now own the pointers that you pass to them), and could cause problems with applications that shared pointers to the same object across multiple volumes.

Hope this helps!

[NBickford-NV]

Closing, since this seems to have been fixed by the commit described in the last post.