Bug 301946 – sci-visualization/paraview-3.6.2 crashs with X11 forwarding

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Oliver Borm 2010-01-23 16:16:26 UTC]

I've recently updated my servers and since then paraview doesn't work anymore, when I login to them with exported display.

client ~$ ssh -YC server#
server ~$ echo $DISPLAY
localhost:10.0

server ~$ paraview
X Error: BadLength (poly request too large or internal Xlib length error) 16
  Extension:    136 (Uknown extension)
  Minor opcode: 17 (Unknown request)
  Resource id:  0x2e0077c
ERROR: In /var/tmp/portage/sci-visualization/paraview-3.6.2/work/ParaView3/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 405
vtkXOpenGLRenderWindow (0x1572200): Could not find a decent visual



ERROR: In /var/tmp/portage/sci-visualization/paraview-3.6.2/work/ParaView3/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 405
vtkXOpenGLRenderWindow (0x1572200): Could not find a decent visual



X Error: BadValue (integer parameter out of range for operation) 2
  Extension:    136 (Uknown extension)
  Minor opcode: 3 (Unknown request)
  Resource id:  0x27
ERROR: In /var/tmp/portage/sci-visualization/paraview-3.6.2/work/ParaView3/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 632
vtkXOpenGLRenderWindow (0x1572200): Cannot create GLX context.  Aborting.

Also when I start a pvdataserver on this server and want to connect to them from my client through python (connecting to the pvdataserver with the paraview GUI works), with for example this simple script:

from paraview.simple import *
Connect(ds_host="server")
Sphere()
Show()
Render()


I get on the server:
server ~$ pvdataserver
Listen on port: 11111
Waiting for client...
Client connected.
ERROR: In /var/tmp/portage/sci-visualization/paraview-3.6.2/work/ParaView3/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 405
vtkXOpenGLRenderWindow (0x8e1810): Could not find a decent visual


[server:27402] *** Process received signal ***
[server:27402] Signal: Segmentation fault (11)
[server:27402] Signal code: Address not mapped (1)
[server:27402] Failing at address: 0x10
[server:27402] [ 0] /lib/libpthread.so.0 [0x7fe17c328de0]
[server:27402] [ 1] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN22vtkXOpenGLRenderWindow13CreateAWindowEv+0x103) [0x7fe1823b5903]
[server:27402] [ 2] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN22vtkXOpenGLRenderWindow16WindowInitializeEv+0x12) [0x7fe1823b4d42]
[server:27402] [ 3] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN22vtkXOpenGLRenderWindow5StartEv+0xd) [0x7fe1823b2c9d]
[server:27402] [ 4] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN15vtkRenderWindow14DoStereoRenderEv+0x10) [0x7fe1822d93a0]
[server:27402] [ 5] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN15vtkRenderWindow10DoFDRenderEv+0x36c) [0x7fe1822d985c]
[server:27402] [ 6] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN15vtkRenderWindow10DoAARenderEv+0x485) [0x7fe1822dab25]
[server:27402] [ 7] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN15vtkRenderWindow6RenderEv+0xe7) [0x7fe1822d9997]
[server:27402] [ 8] /usr/lib64/paraview-3.6/libvtkRendering.so.pv3.6(_ZN22vtkXOpenGLRenderWindow6RenderEv+0x40) [0x7fe1823b3c00]
[server:27402] [ 9] /usr/lib64/paraview-3.6/libvtkPVFilters.so(_ZN30vtkPVClientServerRenderManager9RenderRMIEv+0x11) [0x7fe18af01641]
[server:27402] [10] /usr/lib64/paraview-3.6/libvtkParallel.so.pv3.6(_ZN25vtkMultiProcessController10ProcessRMIEiPvii+0x5d) [0x7fe1839c57ed]
[server:27402] [11] /usr/lib64/paraview-3.6/libvtkParallel.so.pv3.6(_ZN25vtkMultiProcessController11ProcessRMIsEii+0x113) [0x7fe1839c61b3]
[server:27402] [12] /usr/lib64/paraview-3.6/libvtkPVServerCommon.so(_ZN19vtkRemoteConnection20ProcessCommunicationEv+0x26) [0x7fe18b2f8876]
[server:27402] [13] /usr/lib64/paraview-3.6/libvtkPVServerCommon.so(_ZN33vtkProcessModuleConnectionManager18MonitorConnectionsEm+0x22d) [0x7fe18b2b14cd]
[server:27402] [14] /usr/lib64/paraview-3.6/libvtkPVServerCommon.so(_ZN16vtkProcessModule11StartServerEm+0x13e) [0x7fe18b2b700e]
[server:27402] [15] /usr/lib64/paraview-3.6/libvtkPVServerCommon.so(_ZN16vtkProcessModule5StartEiPPc+0x22d) [0x7fe18b2b8c8d]
[server:27402] [16] /usr/lib64/paraview-3.6/libvtkPVFilters.so(_ZN9vtkPVMain3RunEP12vtkPVOptions+0x59) [0x7fe18af3bc59]
[server:27402] [17] /usr/lib64/paraview-3.6/pvdataserver-real(main+0x6b) [0x4013db]
[server:27402] [18] /lib/libc.so.6(__libc_start_main+0xe6) [0x7fe17a243a26]
[server:27402] [19] /usr/lib64/paraview-3.6/pvdataserver-real(_ZNSt8ios_base4InitD1Ev+0x81) [0x401279]
[server:27402] *** End of error message ***
segmentation fault

and on the client:
client ~$ python
Python 2.6.4 (r264:75706, Dec  8 2009, 20:49:52)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from paraview.simple import *
paraview version 3.6.2, Date: 2009-05-18
>>>
>>> Connect(ds_host="server")
Connection (server:11111)
>>> Sphere()
<paraview.servermanager.Sphere object at 0xd999d0>
>>> Show()
vtkSphereSource : [ ...........]
<paraview.servermanager.GeometryRepresentation object at 0x1eb78d0>
>>> Render()
vtkPVGeometryFilter : [ ...........]
vtkPVCacheKeeper : [ ...........]
vtkMPIMoveData : [ ...........]
vtkPainterPolyDataMapper : [ ...........]
vtkMPIMoveData : [ ...........]
vtkOrderedCompositeDistributor : [ ...........]
ERROR: In /var/tmp/portage/sci-visualization/paraview-3.6.2/work/ParaView3/Servers/Common/vtkServerConnection.cxx, line 67
vtkServerConnection (0x1368aa0): Server Connection Closed!

<paraview.servermanager.IceTDesktopRenderView object at 0xd999d0>
>>>

On the server, glxinfo says:
server ~$ glxinfo
name of display: localhost:10.0
Error: couldn't find RGB GLX visual or fbconfig

and xdpyinfo says that I have more than one GLX extension and more than one visual with TrueColor and DirectColor support.

My server has no xorg-server installed and only a ATI ES1000 graphic card and just some programs which I need for openfoam and paraview. This bug does not happen, if I connect from my client to another desktop client with full kde4 installation and Nvidia graphic card installed. My client has also kde4 and Nvidia graphic card.

After two days of headache I found a workaround (from http://forum.parallels.com/showthread.php?t=18081), one has to set on the server after log in:

export LIBGL_ALWAYS_INDIRECT=yes

But why do I have to set the indirect GLX rendering explicit by hand? If I login into another desktop client, this is set by default. And why has it worked before the last update (my last update of this machine was approximately one year ago)?



Reproducible: Always




server ~ $ emerge --info
Portage 2.1.6.13 (default/linux/amd64/10.0/server, gcc-4.3.4, glibc-2.10.1-r1, 2.6.29-gentoo-r5 x86_64)
=================================================================
System uname: Linux-2.6.29-gentoo-r5-x86_64-Dual-Core_AMD_Opteron-tm-_Processor_8218-with-gentoo-1.12.13
Timestamp of tree: Fri, 22 Jan 2010 18:00:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     4.0_p35
dev-lang/python:     2.6.4
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.13
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.63-r1
sys-devel/automake:  1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=opteron -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=opteron -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LDFLAGS="-Wl,-O1"
LINGUAS="de en"
MAKEOPTS="-j9"
PKGDIR="/usr/local/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/layman/science /usr/local/portage/layman/sunrise"
USE="X acl amd64 apache2 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fam fortran gcj gdbm gpm hal hdf5 iconv ipv6 kerberos ldap ldapsam mmx modules mudflap multilib mysql ncurses nfs nls nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection sasl sdl session snmp source spl sse sse2 ssl sysfs tcl tcltk tcpd threads tk truetype unicode xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="r128 radeon radeonhd"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

[Comment 1 Markus Dittrich (RETIRED) 2010-01-28 23:42:44 UTC]

Hi Oliver,

I am not quite sure what we can do about this
from a paraview point of view. It looks to me
that this would affect any application that
does direct rendering with your particular setup.
Any suggestions?

Thanks,
Markus

[Comment 2 Oliver Borm 2010-02-05 14:59:41 UTC]

Hello Markus,

ok I understand that this problem is not a paraview specific one. It seems to be a general OpenGL problem. If I change my opengl implementation with eselect from nvidia to xorg-x11 on a remote desktop machine, where I'm logged in with X11 forwarding, then I run also into this trouble with glxinfo and glxgears.

 ~ $ glxgears                                                           
Error: couldn't get an RGB, Double-buffered visual                                  
 ~ $ glxinfo 
name of display: localhost:10.0
Error: couldn't find RGB GLX visual or fbconfig

So it is maybe a problem with mesa rather than with paraview.

[Comment 3 Markus Dittrich (RETIRED) 2010-02-11 23:47:57 UTC]

(In reply to comment #2)
> Hello Markus,
> 
> ok I understand that this problem is not a paraview specific one. It seems to
> be a general OpenGL problem. If I change my opengl implementation with eselect
> from nvidia to xorg-x11 on a remote desktop machine, where I'm logged in with
> X11 forwarding, then I run also into this trouble with glxinfo and glxgears.
> 
>  ~ $ glxgears                                                           
> Error: couldn't get an RGB, Double-buffered visual                              
>  ~ $ glxinfo 
> name of display: localhost:10.0
> Error: couldn't find RGB GLX visual or fbconfig
> 
> So it is maybe a problem with mesa rather than with paraview.
> 

Hi Oliver,

I've cc'd the X11 folks. Hopefully they can give us some
insight.

Thanks,
Markus

[Comment 4 Julian Ospald 2013-02-11 21:35:53 UTC]

try with sci-visualization/paraview-3.98.0