Title says it all. It probably wasn't detected due to the fact most applications using polyvox only have a couple of simple volumes. In my application, I created and destroyed a vast number of them and my RAM usage skyrocketed.

After using some tools to track down the source of the memory leak, I found that "m_pUncompressedBorderData" wasn't being delete'd from SimpleVolume and "m_tUncompressedData" wasn't being delete'd from SimpleVolume::Block. I was looking in "SimpleVolume.inl" and "SimpleVolumeBlock.inl" for reference.

The leak can fixed by quite simply delete'ing the variables in the destructor of both classes. SimpleVolume already has a destructor in the inl file, but SimpleVolume::Block will need one added in t he header.

After applying this fix, my application's memory usage dropped from 600mb+ to about 50mb after about 60 seconds of walking around my terrain (I use a chunk based system, 16x16x16 size chunks make up the terrain and each chunk uses a SimpleVolume to generate the mesh).

Thanks, but I think this is probably already fixed in Git Master: http://www.volumesoffun.com/phpBB3/viewtopic.php?p=2111#p2111. Let me know if I'm mistaken though.

On a related note, if you are creating/destroying a large number of these volumes (for a paging system?) then you should possibly be using LargeVolume instead.

Well I was using the latest snapshot, not the GIT version, so that's entirely possible.

Also I am using a paging system (of sorts) but my world isn't finetly big. (Well it is, the limitation is the capacity of a int32, like Minecraft) so I have to push lots of small chunks of terrain into Polyvox.