[vtk-developers] Pipeline crashes with multiple UpdateExtent requests

[David Gobbi]

Hi All,

I've been looking at the vtkStreamingDemandDrivenPipeline and have been a
bit surprised about the way UPDATE_EXTENT requests are handled.  Whenever an
AlgorithmOutput gets UPDATE_EXTENT requests from more than one downstream
object, a segfault can occur unless all downstream objects request exactly
the same extent.  Here is a simple tcl example to demonstrate this:

=========
package require vtk

# Simple examle that crashes when an UpdateExtent request
# from one algorithm is overwritten by a smaller UpdateExtent
# request from another algorithm

# read an image that has an extent of 0 255 0 255 0 0
vtkPNGReader reader
reader SetDataSpacing 0.8 0.8 1.5
reader SetFileName "$VTK_DATA_ROOT/Data/fullhead15.png"

# Uncomment this to make the crash disappear
#reader Update

# clip the image down to 0 127 0 127 0 0
vtkImageClip clip
clip SetInputConnection [reader GetOutputPort]
clip SetOutputWholeExtent 0 127 0 127 0 0

# do an operation on the clipped and unclipped data
vtkImageBlend blend
blend SetInputConnection [reader GetOutputPort]
blend AddInputConnection [clip GetOutputPort]

vtkImageViewer viewer
viewer SetInputConnection [blend GetOutputPort]
viewer SetColorWindow 2000
viewer SetColorLevel 1000
viewer Render
==========

Running this example gives this error, followed by a segfault:

ERROR: In /Volumes/Work/Kitware/vtk-git/Filtering/vtkImageData.cxx, line
1472
vtkImageData (0x10630fe10): GetScalarPointer: Pixel (0, 128, 0) not in
memory.
 Current extent= (0, 127, 0, 127, 0, 0)

The reason for the segfault is that the reader is given two UPDATE_EXTENT
requests:
First, the vtkImageBlend requests an extent of 0 255 0 255 0 0.
Second, the vtkImageClip requests an extent of 0 128 0 128 0 0.

The StreamingDemandDriven pipeline does not combine these requests, it just
sets the data extent according to the last UPDATE_EXTENT request.  So, the
vtkImageBlend only gets half of the data that it expects on its first input.
 The pipeline should be more robust than that.  With a properly implemented
pipeline, the tcl example that I ave above should not segfault.

There is no easy fix.  Each AlgorithmOutput has only one UPDATE_EXTENT slot,
and the imaging filters (and the sddp) set that slot directly, without first
checking to see if it has already been set by some other downstream object.
 One fix would be to add a method to the SDDP that combines the update
extents, and then modify the image filters so that they use that method
instead of setting UPDATE_EXTENT directly.  Like I said, not an easy fix.

Has anyone else run into this problem?  Does this also afflict streaming in
the graphics pipeline?

  David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20101124/cbba54f8/attachment.html>