VTK-based applications completely freeze after a couple of hours
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
When running an animation or simulation where VTK objects are updated each frame, VTK completely freezes after a couple of hours.
The problem is caused by VTK's implementation of vtkTimeStamp. The class uses a static 32-bit integer to hold the current 'time', and increments this value every time Modified is called on any VTK object. This number eventually overflows, after which all modified time comparisons in VTK can break.
This behaviour usually occurs within a day, but may occur within a few hours, depending on the number of objects updated each frame.
Note that Paraview also freezes when a animation is left to run overnight.
The documentation of vtkTimeStamp actually states that the overflow can occur, but continues to state that "the typical consequence should be that some filters will update themselves when really they don't need to". Needless to say that the opposite is the case. This problem also occurs when compiling VTK in 64-bits, as the unsigned long type is 32-bits even on 64-bit platforms.
Attached is a patch to fix this issue in VTK 5.10.1. It modifies vtkTimeStamp to use a uint64_t type and replaces the direct use of the unsigned long type throughout VTK to the vtkTimeStamp interface. The vtkTimeStamp implementation itself is only modified for Windows systems, but since only this class would have to be changed it should be trivial to modify for Mac and Linux systems.
The problem still occurs in VTK 6.0, but due to the rearrangement of the code in directories, the patch requires some editing in order to apply it to VTK 6.0 (and probably some other changes would have to be made).
Since this is a major oversight in VTK and the timestamping mechanism is crucial to VTK's functioning, this should also be fixed in VTK 6.0. When using VTK in long running simulations, people are very likely to run into this issue.