Paraview crashes at startup

ParaView Support
1

Hey everybody,

first of all thank you very much for all your effort regarding ParaView. An excellent program for post-processing numerical data…

The following happend:

  • I made a very very stupid mistake on my system
  • I changed the group of all files and folders inside /usr (my fingers were much faster than my thoughts)
  • Doing so, the system gets - lets say - crapified
  • WIth a live-system, I changed everything in /usr to the root group again but found that also different files had wrong permissions
  • Even the vnc server could not connect a new “display” as different permissions and wrong group permissions were set wrongly (never the less, I could resolve most of the problems)

However, paraview is still crashing and I believe it is related (again) to some wrong permissions of some files again but I cannot figure out which files would need to be checked. The error is the following:

shorty@bin: ./paraview
(   2.549s) [paraview        ]vtkXOpenGLRenderWindow.:266    ERR| vtkXOpenGLRenderWindow (0x25a77b0): Could not find a decent config

(   2.549s) [paraview        ]vtkXOpenGLRenderWindow.:484    ERR| vtkXOpenGLRenderWindow (0x25a77b0): Could not find a decent visual


Loguru caught a signal: SIGABRT
Stack trace:
32            0x40802a /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/paraview-real() [0x40802a]
31      0x7f792f0380b3 __libc_start_main + 243
30            0x407c6d /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/paraview-real() [0x407c6d]
29            0x40d336 /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/paraview-real() [0x40d336]
28            0x408f8a /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/paraview-real() [0x408f8a]
27      0x7f792ec97ff0 pqParaViewBehaviors::pqParaViewBehaviors(QMainWindow*, QObject*) + 1104
26      0x7f792ebf1636 pqAlwaysConnectedBehavior::pqAlwaysConnectedBehavior(QObject*) + 310
25      0x7f792ebf14be pqAlwaysConnectedBehavior::serverCheck() + 174
24      0x7f792d5f78fd pqObjectBuilder::createServer(pqServerResource const&, int) + 605
23      0x7f792b5de071 vtkSMSession::ConnectToSelf(int) + 33
22      0x7f792a575578 vtkProcessModule::RegisterSession(vtkSession*) + 376
21      0x7f7924b419e2 /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/../lib/libvtkCommonCore-pv5.10.so.1(+0x5b69e2) [0x7f7924b419e2]
20      0x7f7924a2d359 vtkCallbackCommand::Execute(vtkObject*, unsigned long, void*) + 25
19      0x7f792bd40f20 /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/../lib/libvtkGUISupportQt-pv5.10.so.1(+0x39f20) [0x7f792bd40f20]
18      0x7f792bd2d2cb /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/../lib/libvtkGUISupportQt-pv5.10.so.1(+0x262cb) [0x7f792bd2d2cb]
17      0x7f792c48c1ea QMetaObject::activate(QObject*, int, int, void**) + 1850
16      0x7f792d564fa9 /home/shorty/ParaView-5.10.0-RC1-MPI-Linux-Python3.9-x86_64/bin/../lib/libpqCore-pv5.10.so.1(+0x7ffa9) [0x7f792d564fa9]
15      0x7f792d561c72 pqServerManagerObserver::connectionCreated(long long) + 50
14      0x7f792c48c1ea QMetaObject::activate(QObject*, int, int, void**) + 1850
13      0x7f792d641b26 pqServerManagerModel::onConnectionCreated(long long) + 726
12      0x7f792d560822 pqServerManagerModel::serverAdded(pqServer*) + 50
11      0x7f792c48c1ea QMetaObject::activate(QObject*, int, int, void**) + 1850
10      0x7f792ec57b53 pqDefaultViewBehavior::onServerCreation(pqServer*) + 67
9       0x7f792b4d2683 vtkPVSessionCore::GatherInformation(unsigned int, vtkPVInformation*, unsigned int) + 451
8       0x7f792b4d2324 vtkPVSessionCore::GatherInformationInternal(vtkPVInformation*, unsigned int) + 36
7       0x7f7920fef429 vtkPVRenderingCapabilitiesInformation::CopyFromObject(vtkObject*) + 9
6       0x7f7920fef3f1 vtkPVRenderingCapabilitiesInformation::GetLocalCapabilities() + 305
5       0x7f79291805e5 vtkOpenGLRenderWindow::SupportsOpenGL() + 1029
4       0x7f792921e9c2 vtkXOpenGLRenderWindow::WindowInitialize() + 18
3       0x7f7929222615 vtkXOpenGLRenderWindow::CreateAWindow() + 1893
2       0x7f792f036859 abort + 299
1       0x7f792f05718b gsignal + 203
0       0x7f792f057210 /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f792f057210]
(   2.549s) [paraview        ]                       :0     FATL| Signal: SIGABRT

Any idea or any hint is warmly welcomed.
Based on the first message:

Could not find a decent visual

I guess, it is a similar problem compared to the vnc server.
For information purpose: glxgears works, gnuplot too. But not tested any other VTK application.

Thank you in advance,
Tobi

PS: I removed paraview and re-installed it. I also tried the pre-compiled packages provided at your website. The system is an Ubuntu LTS 20.04 system.

2

Are you able to run glxinfo ? If not, then this is a system issue, not a ParaView issue.

3

Yes, I can run glxinfo. However, one more information. After exporting the following variable:

shorty@bin: export LIBGL_ALWAYS_INDIRECT=y
shorty@bin: ./paraview

(   2.281s) [paraview        ]vtkOpenGLRenderWindow.c:506    ERR| vtkXOpenGLRenderWindow (0x2107d10): Unable to find a valid OpenGL 3.2 or later implementation. Please update your video card driver to the latest version. If you are using Mesa please make sure you have version 11.2 or later and make sure your driver in Mesa supports OpenGL 3.2 such as llvmpipe or openswr. If you are on windows and using Microsoft remote desktop note that it only supports OpenGL 3.2 with nvidia quadro cards. You can use other remoting software such as nomachine to avoid this issue.
(   2.898s) [paraview        ]vtkOpenGLRenderWindow.c:506    ERR| vtkXOpenGLRenderWindow (0x17c95200): Unable to find a valid OpenGL 3.2 or later implementation. Please update your video card driver to the latest version. If you are using Mesa please make sure you have version 11.2 or later and make sure your driver in Mesa supports OpenGL 3.2 such as llvmpipe or openswr. If you are on windows and using Microsoft remote desktop note that it only supports OpenGL 3.2 with nvidia quadro cards. You can use other remoting software such as nomachine to avoid this issue.

Loguru caught a signal: SIGSEGV
Stack trace:
0       0x7ffb7b41d210 /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7ffb7b41d210]
(   2.964s) [paraview        ]                       :0     FATL| Signal: SIGSEGV

So as I told, it should be a system problem as I made that mistake. So probably, no support here right? Nevertheless, the new error gives some more insight and hopefully I am on a good way to resolve it.

Thank you for your feedback Mathieu.
Tobi

4

Doesn’t mean we can’t help you figure it out, but the expertise you are looking for may not be here.

5

I will first check the drivers for the graphic card and everything related to mesa and xorg. Will let you know if I get a solution.

Tobi

6

Hey everybody, so I managed to get more insight. Hence, is it possible to start paraview using mesa rather than the graphic-card driver?

Tobi

7

Indeed, take a look at this:

8

Simply use --mesa Tobi :smiley:
Now it works.

Hi Mathieu, sorry, I had a post in progress but did not submitted it. So thank you for your feedback.

For all: the x2go session uses MESA rather than the graphic card which kills ParaView if we don´t use the --mesa Attribute. So the solution (for pre-compiled paraview) is to start it by adding the flag --mesa. Done :slight_smile:

Tobi

TOPIC: solved

1 Like
9

Right, this works with the binary release !