Weird - I don't seem to be able to reproduce this. Memory stays level for me even if I leave the threshold effect on for a long time.

Can you replicate this on more than one platform? I wonder if it's some kind of driver bug or vtk thing. The slicer code doesn't look to me like it does any allocation per timestep.

I'll leave this running for longer and see what happens.

I've tested it on multiple Win64 computers with the latest release and the problem is reproducible on all (no extensions are installed).

After you wrote that there seems to be no memory allocation, I've checked and the leak occurs whenever a Modified() is called. Just load the MRIHead sample and enter the followings into the Python console:

n=slicer.util.getNode('MRHead')
n.Modified()
n.Modified()
n.Modified()
n.Modified()
n.Modified()

So, this leak is noticeable in the Threshold editor effect because this tool calls Modified() a lot, but the root cause is probably in another module.

Hmm... okay, I guess we can try to narrow that down then. Best thing would be to try turning off modules by type (with --disable-{cli,scripted,loadable}-modules command line options) and then by module as needed. Or if it's in the core we can probably track allocations.

But it's odd that Modified is involved since that is not called during the 'glow' effect of the threshold in the editor. Perhaps it's a similar or unrelated issue.

BTW, I left a win64 machine running with the glow of the threshold effect for several hours and it worked just fine and also according to process explorer there was no memory increase.

This sounds like it could be an issue with the opengl driver.

Another debugging thing to try would be to have the volume not displayed in any slice view and call modified repeatedly. Another option would be to get the sliceView widget directly and call forceRender in a loop to see if that leads to a leak.