I have some polydata that looks reasonable (about 2000 points and vertices).
However, I get a segmentation fault in vtkPolyDataNormals::Update().
This is after I run the polydata through a vtkCleanPolyData.
I have saved the polydata to a vtk file using vtkPolyDataWriter. I will attempt to attach the file.
vtkSmartPointer<vtkPolyDataNormals> normals = vtkSmartPointer<vtkPolyDataNormals>::New();
vtkSmartPointer<vtkCleanPolyData> cleaner = vtkSmartPointer<vtkCleanPolyData>::New();
cleaner->SetInputData(SourceData);
cleaner->ConvertLinesToPointsOff();
cleaner->ConvertPolysToLinesOff();
cleaner->Update(); // I believe this line is not really necessary
normals->SetInputConnection(cleaner->GetOutputPort());
normals->ComputeCellNormalsOn();
normals->Update(); // crashes here
Hi,
Segfaults have a multitude of causes. Since there are obviously lots of code omitted in your post, I think you’re better off by building/getting the VTK libraries with debug information. Also compile your code in debug mode. Then run your program from a debugger (e.g. GDB). It’ll trap the crash and allow you to pinpoint the exact cause by examining the variables contents in each of the scopes of the call stack. You know, Update() is only the topmost context where the crash is ensuing. The root cause is likely deeply burried in the many lower level methods and functions it calls either directly or indirectly.
best,
PC
Hello Paulo,
Thank you for your response. Here is the complete code to demonstrate the crash.
#include <vtkNew.h>
#include <vtkPolyDataNormals.h>
#include <vtkCleanPolyData.h>
#include <vtkPolyDataReader.h>
int main(int argc, char* argv[])
{
vtkNew<vtkPolyDataReader> reader;
reader->SetFileName("/tmp/sc_temp_vtkPolyDataWriter_SourceData_2012_2146.vtk");
reader->Update();
vtkSmartPointer<vtkPolyDataNormals> normals = vtkSmartPointer<vtkPolyDataNormals>::New();
vtkSmartPointer<vtkCleanPolyData> cleaner = vtkSmartPointer<vtkCleanPolyData>::New();
cleaner->SetInputData(reader->GetOutput());
cleaner->ConvertLinesToPointsOff();
cleaner->ConvertPolysToLinesOff();
normals->SetInputConnection(cleaner->GetOutputPort());
normals->ComputeCellNormalsOn();
std::cout << "Before normals->Update()" << std::endl;
normals->Update(); // crashes here
std::cout << "After normals->Update()" << std::endl;
return EXIT_SUCCESS;
}
Before the crash, there are lots of warnings like this
Warning: In /path/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/DataModel/vtkPolyData.cxx, line 1023
vtkPolyData (0x1f0ed70): Building VTK_TRIANGLE 2145 with less than three points, but VTK_TRIANGLE needs at least three points. Check the input.
Are there some options for vtkCleanPolyData to get rid of these bad triangles?
Here is the call stack when we seg fault
#0 0x00007ffff2a4d943 in vtkPolyData::GetCellEdgeNeighbors (this=0x3975860, cellId=2145, p1=0, p2=4500047877230022613, cellIds=0x354a5f0)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/DataModel/vtkPolyData.cxx:1618
#1 0x00007ffff347e3c2 in vtkPolyDataNormals::TraverseAndOrder (this=0x362b420) at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Filters/Core/vtkPolyDataNormals.cxx:553
#2 0x00007ffff347d01c in vtkPolyDataNormals::RequestData (this=0x362b420, inputVector=0x3b7d570, outputVector=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Filters/Core/vtkPolyDataNormals.cxx:326
#3 0x00007ffff2f5d4fa in vtkPolyDataAlgorithm::ProcessRequest (this=0x362b420, request=0x34a81c0, inputVector=0x3b7d570, outputVector=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkPolyDataAlgorithm.cxx:88
#4 0x00007ffff2f3cdbc in vtkExecutive::CallAlgorithm (this=0x3b80170, request=0x34a81c0, direction=1, inInfo=0x3b7d570, outInfo=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkExecutive.cxx:773
#5 0x00007ffff2f35051 in vtkDemandDrivenPipeline::ExecuteData (this=0x3b80170, request=0x34a81c0, inInfo=0x3b7d570, outInfo=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:491
#6 0x00007ffff2f2b30d in vtkCompositeDataPipeline::ExecuteData (this=0x3b80170, request=0x34a81c0, inInfoVec=0x3b7d570, outInfoVec=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:171
#7 0x00007ffff2f34791 in vtkDemandDrivenPipeline::ProcessRequest (this=0x3b80170, request=0x34a81c0, inInfoVec=0x3b7d570, outInfoVec=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:273
#8 0x00007ffff2f7638d in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x3b80170, request=0x34a81c0, inInfoVec=0x3b7d570, outInfoVec=0x3b7d180)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:341
#9 0x00007ffff2f34eac in vtkDemandDrivenPipeline::UpdateData (this=0x3b80170, outputPort=0)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:442
#10 0x00007ffff2f7669c in vtkStreamingDemandDrivenPipeline::Update (this=0x3b80170, port=0, requests=0x0)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:416
#11 0x00007ffff2f76528 in vtkStreamingDemandDrivenPipeline::Update (this=0x3b80170, port=0)
at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:378
#12 0x00007ffff2f23918 in vtkAlgorithm::Update (this=0x362b420, port=0) at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkAlgorithm.cxx:1456
#13 0x00007ffff2f238e3 in vtkAlgorithm::Update (this=0x362b420) at /path/Downloads/OpenFOAM_source/ThirdParty-v2012/ParaView-v5.6.3/VTK/Common/ExecutionModel/vtkAlgorithm.cxx:1450
Hello,
Sorry for the late reply. Well, is there a reason to disable these?
Degenerate primitives remaining in your geometry may be the cause of ill-formed triangles.
take care,
PC
Hello Paulo,
Thanks for the reply. If we change those from Off to On, then the crash goes away, but we get problems with other parts of our code – the cell picker would give us the wrong indices when the user clicks the mouse.
Thanks,
Matthias
Then I believe you need to work with the new indexes that are certainly in effect after cleaning the geometry. If you use the clicked indexes to refer cells in the original data structure you will get wrong results indeed.