[vtk-developers] change to vtkExodusIIReaderPrivate::ResetCache()

[David Thompson]

> From a pull from master some weeks ago, the previous version of this  
> method looked like this:
> ...
> When reading in an exodus file now, the code disappears into the  
> reader and never finishes (maybe it would eventually, but after a  
> long while I kill it).  Adding back in the line to set the cache  
> capacity to 128 resolves this issue.  I expect that the line was  
> removed for a reason.  Did removing the line resolve a problem for  
> someone else?  Is anyone else having difficulty with the exodus  
> reader as a result of this change?  Or is it something specific to  
> my exodus file/runtime environment?

Hi Pat,

The line was removed to address a problem Alan had reported when  
opening many small files with the parallel reader... the sum of the  
caches (one from each sub-reader owned by the parallel reader) was  
growing too large. I haven't heard whether anyone else is having  
problems but Alan reported it fixed his issue. If I had to guess, I  
would say there's some code in there relying on the cache holding on  
to a reference to a vtkDataArray when it should not (even with a  
128MiB cache, there was never any guarantee). If so, valgrind should  
pick up on the reference to freed memory. Can you run your code  
through valgrind and see if it complains?

	David