[vtk-developers] Pipeline crashes with multiple UpdateExtent requests

[David Gobbi]

Hi Berk,

I've put a patch on gerrit that merges update extents, i.e. for when one
output has multiple consumers and each consumer needs a different update
extent.  This is specific to structured data.  Could you take a look?

http://review.source.kitware.com/446
http://www.vtk.org/Bug/view.php?id=11515

Thanks in advance,

  David


On Wed, Nov 24, 2010 at 3:39 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> 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/20101126/53bf210f/attachment.html>