&, bool, bool) + 471
35 0x7fcb0f08cf98 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 296
34 0x7fcb1037e339 QApplication::notify(QObject*, QEvent*) + 5033
33 0x7fcb10378b1c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 156
32 0x7fcb103af6e7 QWidget::event(QEvent*) + 2759
31 0x7fcb10460470 QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 192
30 0x7fcb104602cd /usr/lib/libQt5Widgets.so.5(+0x2602cd) [0x7fcb104602cd]
29 0x7fcb1045ed8a /usr/lib/libQt5Widgets.so.5(+0x25ed8a) [0x7fcb1045ed8a]
28 0x7fcb1045c527 QAbstractButton::clicked(bool) + 71
27 0x7fcb0f0bdc00 /usr/lib/libQt5Core.so.5(+0x2bdc00) [0x7fcb0f0bdc00]
26 0x7fcb0ffdef82 pqPropertiesPanel::apply() + 946
25 0x7fcb0fee2147 pqPropertiesPanel::applied(pqProxy*) + 71
24 0x7fcb0f0bdc00 /usr/lib/libQt5Core.so.5(+0x2bdc00) [0x7fcb0f0bdc00]
23 0x7fcb10ae50b9 pqApplyBehavior::applied(pqPropertiesPanel*, pqProxy*) + 249
22 0x7fcb10ae7d36 pqApplyBehavior::showData(pqPipelineSource*, pqView*) + 1878
21 0x7fcb0fd6c009 pqRenderViewBase::resetDisplay(bool) + 73
20 0x7fcb095ede18 vtkSMRenderViewProxy::ResetCamera(bool) + 280
19 0x7fcb0eaae628 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 120
18 0x7fcb0eaaf0a8 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 264
17 0x7fcb0fb074d6 vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 38
16 0x7fcb0fb06fd8 vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 200
15 0x7fcb0fb06717 vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 1303
14 0x7fcb09b614a9 vtkPVRenderViewCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 12841
13 0x7fcb09598653 vtkPVRenderView::ResetCamera() + 35
12 0x7fcb0959c83e vtkPVRenderView::Update() + 142
11 0x7fcb095ba5d2 vtkPVView::Update() + 290
10 0x7fcb095b58e1 vtkPVView::CallProcessViewRequest(vtkInformationRequestKey*, vtkInformation*, vtkInformationVector*) + 145
9 0x7fcb09532c37 vtkGeometryRepresentationWithFaces::ProcessViewRequest(vtkInformationRequestKey*, vtkInformation*, vtkInformation*) + 23
8 0x7fcb09531473 vtkGeometryRepresentation::ProcessViewRequest(vtkInformationRequestKey*, vtkInformation*, vtkInformation*) + 227
7 0x7fcb09531363 vtkGeometryRepresentation::ComputeVisibleDataBounds() + 115
6 0x7fcb0952dccd vtkGeometryRepresentation::GetBounds(vtkDataObject*, double*, vtkCompositeDataDisplayAttributes*) + 77
5 0x7fcb0dabab8b vtkCompositeDataDisplayAttributes::ComputeVisibleBounds(vtkCompositeDataDisplayAttributes*, vtkDataObject*, double*) + 107
4 0x7fcb0daba9db vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal(vtkCompositeDataDisplayAttributes*, vtkDataObject*, vtkBoundingBox*, bool) + 491
3 0x7fcb0dabaade vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal(vtkCompositeDataDisplayAttributes*, vtkDataObject*, vtkBoundingBox*, bool) + 750
2 0x7fcb0c6fadb6 vtkPolyData::GetCellsBounds(double*) + 22
1 0x7fcb0c70b0df /opt/paraview/bin/../lib/libvtkCommonDataModel.so.1(+0x30b0df) [0x7fcb0c70b0df]
0 0x7fcb10e07a00 /usr/lib/libc.so.6(+0x38a00) [0x7fcb10e07a00]
( 13.103s) [paraview] :0 FATL| Signal: SIGSEGV
Segmentation fault (core dumped)
```
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 11, 2023, 11:35am UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/2 "2023-01-11T11:35:02Z")
There are 2 scenarios, either the data are not written properly, or there is a vtk bug in vtkPolyData::GetCellsBounds. Would you mind providing us with a summary of your data and also write them in ascii format?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 11, 2023, 12:08pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/3 "2023-01-11T12:08:07Z")
Even if there is an issue with the data, ComputeCellBounds should not deallocate when nothing was allocated.
```auto
Thread 1 "paraview" received signal SIGABRT, Aborted.
0x00007ffff7e3d64c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7e3d64c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7ded958 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7dd753d in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7e317ee in ?? () from /usr/lib/libc.so.6
#4 0x00007ffff7e473dc in ?? () from /usr/lib/libc.so.6
#5 0x00007ffff7e4937c in ?? () from /usr/lib/libc.so.6
#6 0x00007ffff7e4bba3 in free () from /usr/lib/libc.so.6
#7 0x00007ffff06ac2ac in vtkPolyData::ComputeCellsBounds (this=0x55555f4eba00) at /home/glow/dev/paraview/pv1/src/VTK/Common/DataModel/vtkPolyData.cxx:526
#8 0x00007ffff06ac30a in vtkPolyData::GetCellsBounds (this=0x55555f4eba00, bounds=0x7fffffffc440) at /home/glow/dev/paraview/pv1/src/VTK/Common/DataModel/vtkPolyData.cxx:53l4 e
#9 0x00007ffff350e520 in vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal (cda=0x55555f577070, dobj=0x55555f4eba00, bbox=0x7fffffffc5a0, parentVisible=true) at /home/glow/dev/paraview/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:334
#10 0x00007ffff350e45e in vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal (cda=0x55555f577070, dobj=0x55555f923240, bbox=0x7fffffffc5a0, parentVisible=true) -at /home/glow/dev/paraview/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:323 s
#11 0x00007ffff350e2a0 in vtkCompositeDataDisplayAttributes::ComputeVisibleBounds (cda=0x55555f577070, dobj=0x55555f923240, bounds=0x5555556c8e58) at /home/glow/dev/paraviewi/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:297 i
#12 0x00007fffec3b1d42 in vtkGeometryRepresentation::GetBounds (dataObject=0x55555f923240, bounds=0x5555556c8e58, cdAttributes=0x55555f577070) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentation.cxx:552
#13 0x00007fffec3b6222 in vtkGeometryRepresentation::ComputeVisibleDataBounds (this=0x5555556c8ca0) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentation.cxx:1570
#14 0x00007fffec3b14ac in vtkGeometryRepresentation::ProcessViewRequest (this=0x5555556c8ca0, request_type=0x5555556d9390, inInfo=0x5555579ffd30, outInfo=0x55555f921800) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentation.cxx:404
#15 0x00007fffec3c156f in vtkGeometryRepresentationWithFaces::ProcessViewRequest (this=0x5555556c8ca0, request_type=0x5555556d9390, inInfo=0x5555579ffd30, outInfo=0x55555f92l1800) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentationWithFaces.cxx:62 e
#16 0x00007fffec53b073 in vtkPVView::CallProcessViewRequest (this=0x555557d387e0, type=0x5555556d9390, inInfo=0x5555579ffd30, outVec=0x5555579c0850) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkPVView.cxx:582
```
---
### Author:  [@FanWang10](https://discourse.paraview.org/u/FanWang10)
#### Post date: [January 12, 2023, 3:12am UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/4 "2023-01-12T03:12:54Z")
Hello,
Sorry for the late reply and thank you for your help!
I fixed the problem, the reason is because I give the wrong point index to the connectivity element.
---
### Author:  [@FanWang10](https://discourse.paraview.org/u/FanWang10)
#### Post date: [January 12, 2023, 3:15am UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/5 "2023-01-12T03:15:12Z")
Hello,
Thank you for your help!
I solved the problem by assigning correct point index to the connectivity element. Maybe that’s the reason related to the ComputeCellBounds. By the way, may I ask what does the ComputeCellBounds do?
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 12, 2023, 10:38am UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/6 "2023-01-12T10:38:46Z")
It can extract the bounds of only the points that are used by the cells of the dataset.
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 12, 2023, 11:29am UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/7 "2023-01-12T11:29:15Z")
If you were writing wrong ids (probably out of bounds), it makes sense for the segfault to occur, because you were accessing out of bounds information.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 12, 2023, 2:36pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/8 "2023-01-12T14:36:28Z")
> [@spyridon97](#):
>
> it makes sense for the segfault to occur, because you were accessing out of bounds information.
An error would be excepted, a segfault is not acceptable and should be fixed imo.
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 12, 2023, 2:56pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/9 "2023-01-12T14:56:59Z")
Well to get an error in the following code:
```nohighlight
for (vtkIdType cellId = 0; cellId < numCells; ++cellId)
{
cellArray->GetCellAtId(cellId, npts, pts, cellPointIds);
for (ptIdx = 0; ptIdx < npts; ++ptIdx)
{
ptUses[pts[ptIdx]] = 1;
}
}
```
we would have to add a check if `pts[ptIdx]] < numPts`. As you can see this will add a significant overhead to the computation. There are multiple checks above such:
```nohighlight
if (numPDCells <= 0)
{
vtkMath::UninitializeBounds(this->CellsBounds);
return;
}
```
```nohighlight
if (this->Points == nullptr || numPts <= 0)
{
vtkMath::UninitializeBounds(this->CellsBounds);
return;
}
```
Which can catch a lot of special cases, but we can’t assume at every single step of an algorithm that an error might occur, otherwise performance will be severely degraded.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 12, 2023, 2:58pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/10 "2023-01-12T14:58:33Z")
> but we can’t assume at every single step of an algorithm that an error might occur, otherwise performance will be severely degraded.
Correct, this should be checked earlier in the I/O code, not in computing code.
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 12, 2023, 3:03pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/11 "2023-01-12T15:03:50Z")
With my correctness hat on, i have to agree with you. With my performance hat on and knowing the 99% of the time the data are correct. i will have to argue that this is not the right thing to do, at least all the time. Maybe a DataSet Validator filter that each reader could execute optionally or execute the validator outside the reader would be the way to go.
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [January 16, 2023, 6:37pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/12 "2023-01-16T18:37:29Z")
I’m pretty sure I can make a very fast test in the code, but maybe a better way would be to test if `pts[ptIdx]] \< numPts’ only in debug builds?
With regards to speed, the for loop itself is horrible - and slow. Any idea what npts is generally? 1, or 4, or 9?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2023, 8:39am UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/13 "2023-01-17T08:39:14Z")
It doesn’t really matter. Used-in-production software are not supposed to segfault, ever.
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [January 18, 2023, 8:45pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/14 "2023-01-18T20:45:42Z")
I agree, Mathieu. Further, I believe the call to GetCellAtId isn’t exactly fast. I would say we just add the check.
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 18, 2023, 9:47pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/15 "2023-01-18T21:47:15Z")
GetCellAtId has been highly optimized to not even perform a copy if possible.
I also agree with the statement that used-in-production software is not supposed to segfault, ever.
I will repeat to make my point clear. Algorithms that are designed for the highest possible performance should not be deteriorated to perform error checking of input. If we were to do this here, i would argue that we should do everywhere that GetCellAtId is used throught VTK/ParaView. As you can imagine this will reduce the performance of many algorithms.
If we want a solution to this problem, we could avoid this error by performing a check at the I/O stage as @mwestphal suggested. We could use the vtkCellArray::IsValid function and also check that the maximum/minimum ids in the connectivity array make sense wrt to the number of points. This could happen at the end of every I/O reader that produces a vtkPolyData/vtkUnsturcturedGrid/vtkExplicitStructuredGrid. Would you agree to something like that?
@wascott @cory.quammen thoughts?
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [January 19, 2023, 6:24pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/16 "2023-01-19T18:24:19Z")
This makes sense to me. Note that readers are frequently bottle-necked by IO. That is why we spent so much time trying to figure out how to not read more than needed for Exodus files. My guess is that IO will be vastly larger than sanity checks of the data.
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [January 22, 2023, 11:07pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/17 "2023-01-22T23:07:53Z")
Sounds like a good idea to add an option in ParaView general settings which validates the output vtk dataobject of all readers. We can leave it enabled by default - so no more segfault for corrupt connectivity. However, for scripts, or repeated runs it’s up to users to disable the sanity checks when the datasets are known to be correct.
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 22, 2023, 11:13pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/18 "2023-01-22T23:13:34Z")
It’s more common for the input of a VTK algorithm (output of a reader) to be wrong rather than the output of a VTK algorithm, but it would be beneficial to test both.
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [January 22, 2023, 11:20pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/19 "2023-01-22T23:20:25Z")
Interesting. Didn’t think of validating the output of a ParaView filter in general. But I can see how it is beneficial. There are a few times when ParaView segfaults while computing the volume/surface representation from the output of a filter. I’m sure you know of a way to multithread the dataset validation procedures. How much of an overhead will it be?
---
### Author:  [@spyridon97](https://discourse.paraview.org/u/spyridon97)
#### Post date: [January 22, 2023, 11:23pm UTC](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148/20 "2023-01-22T23:23:31Z")
I don’t think it’s going to be significant enough. IO will always be the bottleneck especially if you just want to parse your vtkCellArray only once…
[Next page](https://discourse.paraview.org/t/segmentation-fault-loguru-caught-a-signal-sigsegv/11148.md?page=2)