[vtkusers] vtkTimeStamp::Modified() unsigned long overflow

[Wim Koomen]

Dear all,

At my company we have been using VTK for a while now and recently we
noticed some strange behaviour whereby our VTK-based application would
stop updating after running an animation for several hours. We drilled
this problem down to an overflow in the unsigned long that is used
throughout VTK for keeping track of modifications (usually based on
vtkTimeStamp::GetMTime() and vtkTimeStamp::Modified()).

The documentation for vtkTimeStamp::Modified() states the following:
"The current time is just a monotonically increasing unsigned long
integer. It is possible for this number to wrap around back to zero.
This should only happen for processes that have been running for a
very long time, while constantly changing objects within the program.
When this does occur, the typical consequence should be that some
filters will update themselves when really they don't need to."

Especially the last part of this statement is confusing to me.
According to my reasoning, in most cases, classes that make use of the
vtk modified time will not update at all after an overflow/wrap
around.

Take for instance the following code in ComputeMatrix() (vtkProp3D.cxx:389)

if ( this->GetMTime() > this->MatrixMTime )

This will never go to true in the following sequence of events:

1. this->MatrixMTime.Modified() gets called when the static unsigned
long in vtkTimeStamp has a value below 2^32.
2. Modifications elsewhere in the code cause an overflow in that
static unsigned long.
3. Modified() gets called on vtkProp3D.

Result: this->MatrixMTime is a value near 2^32 and this->GetMTime()
will be close to zero.

After this, the code on line 389 will not evaluate to true for a very
long time, if ever. This is the complete opposite of what the
documentation on this says. Instead of doing an extra unnecessary
update the update will not happen anymore.

This kind of code is all throughout VTK, so it hard to avoid sometime
like this happening in a VTK application. In fact, we observed exactly
the same behaviour in ParaView when running an animation for a long
time (several hours). The animation stops running and the application
stop accepting user input.

My questions:
- Is the documentation making a wrong statement here?
- To mitigate this problem, wouldn't it be good idea to change the
vtkTimeStamp unsigned long to a guaranteed 64bit value?

Regards,

Wim