&, bool) + 461
44 0x7f80b6c15c08 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 264
43 0x7f80b8711c78 QApplication::notify(QObject*, QEvent*) + 4024
42 0x7f80b8709c8c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 156
41 0x7f80b87469d8 QWidget::event(QEvent*) + 488
40 0x7f80b87fd4c5 QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 213
39 0x7f80b87fd312 /home/ttjrjw2/Software/Paraview581/bin/../lib/libQt5Widgets.so.5(+0x253312) [0x7f80b87fd312]
38 0x7f80b87fc014 /home/ttjrjw2/Software/Paraview581/bin/../lib/libQt5Widgets.so.5(+0x252014) [0x7f80b87fc014]
37 0x7f80b87fbe02 QAbstractButton::clicked(bool) + 50
36 0x7f80b6c41c47 QMetaObject::activate(QObject*, int, int, void**) + 1511
35 0x7f80b7fb78d2 pqPropertiesPanel::apply() + 1106
34 0x7f80b7e87142 pqPropertiesPanel::applied(pqProxy*) + 50
33 0x7f80b6c41c47 QMetaObject::activate(QObject*, int, int, void**) + 1511
32 0x7f80b8cac65a pqApplyBehavior::applied(pqPropertiesPanel*, pqProxy*) + 154
31 0x7f80b8cad8e5 pqApplyBehavior::showData(pqPipelineSource*, pqView*) + 437
30 0x7f80abbfb998 vtkSMParaViewPipelineControllerWithRendering::ShowInPreferredView(vtkSMSourceProxy*, int, vtkSMViewProxy*) + 360
29 0x7f80abbf982b vtkSMParaViewPipelineControllerWithRendering::UpdatePipelineBeforeDisplay(vtkSMSourceProxy*, int, vtkSMViewProxy*) + 155
28 0x7f80b6015a60 vtkSMSourceProxy::UpdatePipeline(double) + 176
27 0x7f80b5f9f8a1 vtkSMOutputPort::UpdatePipelineInternal(double, bool) + 193
26 0x7f80b5f05b75 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 53
25 0x7f80b5f06abb vtkPVSessionCore::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 59
24 0x7f80b5f06c85 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 245
23 0x7f80b5484ddd vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 29
22 0x7f80b5484aae vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 1198
21 0x7f80b5483fea vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 330
20 0x7f80b5483cf5 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 325
19 0x7f80ad0ddee3 vtkSISourceProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 1507
18 0x7f80b5f41d24 vtkSISourceProxy::UpdatePipeline(int, double, bool) + 484
17 0x7f80b158ff1f vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*) + 255
16 0x7f80b1550f9a vtkDemandDrivenPipeline::UpdateData(int) + 138
15 0x7f80b158e9c1 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 801
14 0x7f80b1551fc6 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 262
13 0x7f80b154b83a vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*) + 330
12 0x7f80b158e9c1 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 801
11 0x7f80b1552467 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1447
10 0x7f80b154cac1 vtkCompositeDataPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 257
9 0x7f80b154f8c7 vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 55
8 0x7f80b1555330 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 64
7 0x7f809b821432 vtkPOpenFOAMReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 786
6 0x7f809aa5429e vtkOpenFOAMReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1278
5 0x7f809aa52f3a /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xe1f3a) [0x7f809aa52f3a]
4 0x7f809aa430a5 /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xd20a5) [0x7f809aa430a5]
3 0x7f809aa67f4c /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xf6f4c) [0x7f809aa67f4c]
2 0x7f809aa5ab7e /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xe9b7e) [0x7f809aa5ab7e]
1 0x7f80b913ea63 /lib64/libc.so.6(+0xa5a63) [0x7f80b913ea63]
0 0x7f80b90d25a0 /lib64/libc.so.6(+0x395a0) [0x7f80b90d25a0]
( 64.966s) [paraview] :0 FATL| Signal: SIGSEGV
Segmentation fault (core dumped)
```
I was wondering if anyone had encountered similar problems, or knew of a way to fix this, apologies if this is the wrong place to post. I’ve also posted the problem to CFD Online at the following link:
> **[\[OpenFOAM\] Segementation Fault when opening data -- CFD Online Discussion Forums](https://www.cfd-online.com/Forums/paraview/232471-segementation-fault-when-opening-data.html#post790716)**
Many thanks,
Jack
---
### Author:  [@tomF](https://discourse.paraview.org/u/tomF)
#### Post date: [December 16, 2020, 12:51pm UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/2 "2020-12-16T12:51:24Z")
Hi Jack,
tl;dr: I noticed the same, workaround is to use Decomposed Case, there may be some things that influence the behavior.
My experience has been similar. There are a few things that influence the behavior I found out:
1. Mesh size. Larger meshes will have this issue but small meshes will not (Not sure what the threshold is, it also depends on 2.)
2. Mesh type: Tetrahedral meshes are giving these issues much less frequent than polyhedral/hexcore (snappyHexMesh) meshed. Not sure about pure hexahedral meshes as I rarely have those for large cases.
As the mesh size influences this problem the most I suspect it has something to do with memory, but that is just a hypothesis that I never got confirmed.
My work-around is to use the reader with a decomposed case. The only downside to that is that if I want to use feature edges to highlight boundaries of patches it may also show processor boundaries, which I typically do not care too much about.
If someone has more insights I would like to learn as well.
Other things that may influence this:
a. Operating system (There were cases where colleagues running Windows could open a particular case and I could not from my linux workstation (or vice versa, my own memory is not that clear about this))
b. Graphics card (Same with the different operating system, my colleagues have different graphics cards)
Best Regards,
Tom
The behavior is consistent between paraview/pvpython/pvbatch and there does not seem to be a difference whether I am working in client/server mode or just in the client, except for maybe changes between the graphics card used in our cluster (the server) and my workstation.
---
### Author:  [@roland](https://discourse.paraview.org/u/roland)
#### Post date: [December 22, 2020, 5:38pm UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/3 "2020-12-22T17:38:38Z")
Hello,
I have exactly the same problem and I have tried several ParaView versions, including 5.9.0-RC2. All on (Debian) linux.
Like Tom I decompose the cases that crash. A decomposition into 2 parts is enough.
It always happens with larger meshes (tens of millions of cells), but I don’t know the exact limit.
I can provide a test case, if necessary.
Kind regards,
Roland
---
### Author:  [@Joachim\_P](https://discourse.paraview.org/u/Joachim_P)
#### Post date: [December 23, 2020, 10:35am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/4 "2020-12-23T10:35:41Z")
Roland,
Please provide a test case and the reader options you specify so we can investigate what is going on here.
Regards,
J.
---
### Author:  [@roland](https://discourse.paraview.org/u/roland)
#### Post date: [December 24, 2020, 2:57pm UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/5 "2020-12-24T14:57:18Z")
Hi Joachim,
I have just sent you a private message with a link to a test case.
This mesh is created using the snappyHexMesh utility, but we have similar problems with (OpenFOAM) meshes created by ANSA.
Included is a state file created by 5.9.0-RC3. It loads the decomposed data, but when you change the ‘Case Type’ to ‘Reconstructed Case’ (and hit ‘Apply’) ParaView crashes. A log of this is also included.
Let me know if you need more information.
Merry Christmas!
Kind regards,
Roland
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 7, 2021, 7:48am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/6 "2021-01-07T07:48:37Z")
@Joachim_P and @tomF
Saw this before the break, but didn’t look at it further. I highly suspect that this is due to the handling of _faces_ in the reader which internally uses a private _vtkFoamLabelVectorVector_ struct. This structure corresponds approximately to the OpenFOAM _faceCompactList_ in that the list of lists is stored as data + offset indices.
The indices are thus sized (nFaces \* nVertsPerFace), which can easily overflow the capacity of an `int32_t`, even when the total number of faces/cells/points are well within the limit. If you inspect the header of the “_polyMesh/faces_” files, it is quite likely that the serial case has `class faceList;` whereas the decompose case has `class faceCompactList;`. When generating these files within OpenFOAM we check if the running index for the compact format would exceed the label limit (eg, 32bit) and revert to using a faceList instead for those cases. The VTK reader on the other hand, handles both internally as a compact list and will thus experience these overflows.
Possible fixes:
- always use a vtkTypeInt64Array for the Indices of vtkFoamLabelVectorVectorImpl (or a vtkIdTypeArray?, or a vtkTypeUInt64Array?)
- same as above, but provide as second template parameter to vtkFoamLabelVectorVectorImpl (for the indecisive)
/mark
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 12, 2021, 5:26pm UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/7 "2021-01-12T17:26:22Z")
Added as [issue 8082](https://gitlab.kitware.com/vtk/vtk/-/issues/18082) and tackling while examining [issue 8081](https://gitlab.kitware.com/vtk/vtk/-/issues/18081). Hope to get something on a merge request in the next few days, and would like someone to test.
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 15, 2021, 7:13am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/8 "2021-01-15T07:13:30Z")
Changes in [MR 75319](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7531) that I hope will cure the overflows.
@tomF or @roland would need to check if these changes solve your problems.
---
### Author:  [@tomF](https://discourse.paraview.org/u/tomF)
#### Post date: [January 15, 2021, 8:51am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/9 "2021-01-15T08:51:30Z")
Sure, I guess we would need to wait for the merge request to be accepted and then to have it implemented in the new ParaView 5.9 release?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 15, 2021, 9:10am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/10 "2021-01-15T09:10:48Z")
It won’t be in 5.9 as the release split occured weeks ago already.
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 15, 2021, 10:39am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/11 "2021-01-15T10:39:19Z")
@tomF - are you in the position to build from source? Can either build based on the merge-request, and/or we can test a few minor changes, but need to see if we can make it a minimal patch.
---
### Author:  [@tomF](https://discourse.paraview.org/u/tomF)
#### Post date: [January 15, 2021, 11:18am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/12 "2021-01-15T11:18:23Z")
Unfortunately I now see that I would need to update a lot on my system and I do not want to break other things, so I am afraid I cannot help. But maybe @roland can manage it.
---
### Author:  [@roland](https://discourse.paraview.org/u/roland)
#### Post date: [January 18, 2021, 4:40pm UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/13 "2021-01-18T16:40:49Z")
I’ve had a try, but either I did something wrong, or the problem was not solved.
What I did was this: I’ve merged the branch ‘olesen/vtk-openfoam-mixed-precision’ to a clone of VTK. This I’ve used to build ParaView. I couldn’t build the GUI (only QT 5.11, while 5.12 is required), but pvpython was no problem. This version of pvpython crashed when trying to open a certain reconstructed data set, but not the decomposed version.
@olesenm, is there a way to check that my build really includes your updated code? Or else can I send you the same data set that I’ve send to @Joachim_P?
Kind regards,
Roland
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 19, 2021, 1:18pm UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/14 "2021-01-19T13:18:35Z")
Hi @roland - if you have a convenient way to make a data set available, it would likely help.
Email address as per the git commit(s)
---
### Author:  [@roland](https://discourse.paraview.org/u/roland)
#### Post date: [October 4, 2021, 9:36am UTC](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063/15 "2021-10-04T09:36:31Z")
Hi Mark,
I’ve just tested 5.10.0-RC1 and my test case opened flawlessly in it. Thanks for the good work!
Kind regards,
Roland