I’m getting a seg fault when trying to extract a cut boundary…I think. I’m using Visual Studio and Python 3.8, which don’t work together yet, so I can see the cxx code at the point of failure, but have no idea how I got here.
The culprit code is in Common/DataModel/vtkPolyData.cxx, current head, lines 149…
vtkCell* vtkPolyData::GetCell(vtkIdType cellId)
{
if (!this->Cells)
{
this->BuildCells();
}
const TaggedCellId tag = this->Cells->GetTag(cellId);
The polydata has four polys, apparently all degenerate, so down in BuildCells, it throws at line 932, catches at line 958, sets ‘this->Cells = nullptr’ and returns. Seg fault occurs immediately on the last line quoted above (and I see the same and similar patterns elsewhere in this file).
Should BuildCells be returning an ‘EmptyCells’, or should the GetCell code check for null and set ‘tag’ to some none-ish value, or ???
I’m trying to track down the root cause (why and where we’re producing a degenerate poly), but it seems like GetCell and friends should not be seg faulting like this.
OK, if it is not fixed there then it would be a great help if you could submit a merge request with a test that reproduces the issue and a proposed fix. Details of of how to create merge request are described here: https://github.com/Kitware/VTK/blob/master/CONTRIBUTING.md.
There should be a message in the error log explaining why BuildCells failed. The line numbers seem to have changed slightly in the current master, but I think you’re hitting this condition:
if (size < 3)
{
throw std::runtime_error("Invalid cell size for polys.");
}
This checks that all cells in the Polys cell array are defined with at least three points. The Polys cell array must only contain VTK_TRIANGLE, VTK_QUAD, or VTK_POLYGON cells, all of which require at least 3 points to be valid.
Can you verify that your polydata is correctly defined?
I’m not sure if there’s a policy for that. We use them internally, but I can’t think of a place where they’re used in API.
These particular exceptions are just implementation details, and are always caught and handled before they would escape an API boundary by logging an error and discarding the exception: