PV 5.7.0-RC2 Aborts Upon Startup


Trying to run the Linux binaries accessed through a remote server using X2GO

“paraview --mesa-llvm” results in the following:

(  10.726s) [paraview        ]vtkXOpenGLRenderWindow.:296    ERR| vtkXOpenGLRenderWindow (0x45154b0): Could not find a decent config

(  10.726s) [paraview        ]vtkXOpenGLRenderWindow.:516    ERR| vtkXOpenGLRenderWindow (0x45154b0): Could not find a decent visual

Loguru caught a signal: SIGABRT
Stack trace:
32            0x40771d paraview() [0x40771d]
31      0x2b1c04880495 __libc_start_main + 245
30            0x407530 paraview() [0x407530]
29            0x40c10b paraview() [0x40c10b]
28            0x4085d9 paraview() [0x4085d9]
27      0x2b1c04d61228 pqParaViewBehaviors::pqParaViewBehaviors(QMainWindow*, QObject*) + 2760
26      0x2b1c04ce2612 pqAlwaysConnectedBehavior::pqAlwaysConnectedBehavior(QObject*) + 226
25      0x2b1c04ce24c5 pqAlwaysConnectedBehavior::serverCheck() + 117
24      0x2b1c06de3167 pqObjectBuilder::createServer(pqServerResource const&, int) + 199
23      0x2b1c091e2179 vtkSMSession::ConnectToSelf(int) + 105
22      0x2b1c0a9213de vtkProcessModule::RegisterSession(vtkSession*) + 142
21      0x2b1c1800e2a6 /home/shelf1/Software/paraview/5.7.0-RC2/bin/../lib/libvtkCommonCore-pv5.7.so.1(+0x4302a6) [0x2b1c1800e2a6]
20      0x2b1c17e61889 vtkCallbackCommand::Execute(vtkObject*, unsigned long, void*) + 25
19      0x2b1c0761fd4c /home/shelf1/Software/paraview/5.7.0-RC2/bin/../lib/libvtkGUISupportQt-pv5.7.so.1(+0x39d4c) [0x2b1c0761fd4c]
18      0x2b1c0760c527 /home/shelf1/Software/paraview/5.7.0-RC2/bin/../lib/libvtkGUISupportQt-pv5.7.so.1(+0x26527) [0x2b1c0760c527]
17      0x2b1c0617cc47 QMetaObject::activate(QObject*, int, int, void**) + 1511
16      0x2b1c06d84b59 /home/shelf1/Software/paraview/5.7.0-RC2/bin/../lib/libpqCore-pv5.7.so.1(+0x76b59) [0x2b1c06d84b59]
15      0x2b1c06d802d2 pqServerManagerObserver::connectionCreated(long long) + 50
14      0x2b1c0617cc47 QMetaObject::activate(QObject*, int, int, void**) + 1511
13      0x2b1c06e2ee12 pqServerManagerModel::onConnectionCreated(long long) + 770
12      0x2b1c06d7f142 pqServerManagerModel::serverAdded(pqServer*) + 50
11      0x2b1c0617cc47 QMetaObject::activate(QObject*, int, int, void**) + 1511
10      0x2b1c04d2bef3 pqDefaultViewBehavior::onServerCreation(pqServer*) + 67
9       0x2b1c094c8fc2 vtkPVSessionCore::GatherInformation(unsigned int, vtkPVInformation*, unsigned int) + 34
8       0x2b1c094c8e53 vtkPVSessionCore::GatherInformationInternal(vtkPVInformation*, unsigned int) + 115
7       0x2b1c08513999 vtkPVRenderingCapabilitiesInformation::CopyFromObject(vtkObject*) + 9
6       0x2b1c08513955 vtkPVRenderingCapabilitiesInformation::GetLocalCapabilities() + 405
5       0x2b1c126ce26d vtkOpenGLRenderWindow::SupportsOpenGL() + 989
4       0x2b1c1276a1f2 vtkXOpenGLRenderWindow::WindowInitialize() + 18
3       0x2b1c1276dc01 vtkXOpenGLRenderWindow::CreateAWindow() + 1873
2       0x2b1c048959b8 abort + 328
1       0x2b1c048942c7 gsignal + 55
0       0x2b1c04894340 /lib64/libc.so.6(+0x36340) [0x2b1c04894340]
(  10.727s) [paraview        ]                       :0     FATL| Signal: SIGABRT

Server is running Scientific Linux 7
“glxinfo | grep OpenGL” returns:

OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.4.2)

Any idea what the issue may be? I can provide more information as requested.



In ParaView 5.7, how you start paraview with mesa-llvm has changed. Try this:

paraview-mesa paraview --backend llvmpipe


Ah, I was unaware. Indeed that does the trick.

I also found that if I include the “mesa” subdirectory in my LD_LIBRARY_PATH I can launch with just “paraview”. Do you see any reason to not use this method?

In either case, it launches with ~16 warnings of :

Error: Unsupported device
WARNING: Failed to initialize RTW VisRTX backend.

Yet it looks like the correct backend is used:


Are these warnings themselves erroneous then?

Yeah, we need to emphasize this in the forthcoming release notes.

That should be fine. That’s all the script paraview-mesa is doing.

These warnings can be ignored in RC2. They have been removed from RC3.

Thanks Cory!

One followup for a full understanding. And let’s pretend client-server mode and aliases don’t exist for a second…
Most of our users use PV remotely so it would be nice if the default was the one-word “paraview” command, but then could the few with Linux boxes who would like to use hardware-based rendering easily override the mesa call?

I’m not sure I fully understand, but I’ll try to answer. Running paraview-mesa paraview should give you hardware rendering when available. So you could have a short launcher script that adds the --backend argument by default and omits it if a user provides an argument to override it. Does that help?

Ok, I thought that paraview-mesa paraview would always force software rendering.
And I suppose with a launcher script one could do about anything.

Thanks again.

Actually, I believe that is right. I don’t have a linux box with physical hardware so can’t verify for sure, but my reading of the launcher code says llvmpipe will be used by default by paraview-mesa. Sorry for the confusion.