[vtkusers] segfault on cell picking, and solution
David Gobbi
david.gobbi at gmail.com
Fri Mar 1 14:12:59 EST 2013
Hi Robert,
I'd like to get a feel for whether or not this might be is a bug.
Were you building the polydata yourself (i.e. from scratch)
or was it produced by a filter? And if the latter, what filter
was producing it?
Going a bit further, was the polydata that you were picking
also being used as an input to a filter, i.e. were you picking
a polydata that was somewhere in the middle of a pipeline?
And if so, what filter?
It seems to me that your application shouldn't have to call
DeleteCells() unless your application is also building the
polydata from scratch. If your application is using VTK
sources, readers, or filters to produce the polydata then
really VTK should be calling DeleteCells()/BuildCells()
automatically, and if VTK isn't doing this, then there must
be a bug somewhere e.g. in one of the filters you are using.
- David
On Fri, Mar 1, 2013 at 10:35 AM, Robert Dean <bob.dean at gmail.com> wrote:
> Hello,
>
> For a long time I had an issue where my application would randomly crash
> while picking cells. Each time the stack dump was in the depths of the vtk
> code. What I tracked it down to was that when an actor is first clicked,
> vtk allocates an internal cell array to assist in mapping the click to cell
> index. This array is not automatically resized on future clicks.
>
> Therefore when the actor is first clicked an array of N is allocated. If the
> array is then updated to contain N*2 cells, clicking cells N through 2N-1
> will access outside the cell index array, resulting in the segfault.
>
> As cell picking is a rare event in the application timing, the solution was
> to call polydata->DeleteCells() method on each update.
>
> Posting in case someone else runs into the same problem. I am currently
> using vtk 5.10, so I do not know if a newer version addresses this issue.
>
> -Bob
More information about the vtkusers
mailing list