search

CDAT / cdat

Community Data Analysis Tools
Other
174 stars 68 forks source link

vtkXOpenGLRenderWindow: Could not find a decent visual #1134

Closed durack1 closed 9 years ago

durack1 commented 9 years ago

There appears to be a problem which is being reproduced across a number of systems: ocean:2015-02-25 ERROR: In /export/doutriaux1/build/build/ParaView/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 382 vtkXOpenGLRenderWindow (0x2a1d710): Could not find a decent visual gfdl-public1:v2.1.0: ERROR: In /home/p1d/PCMDI_METRICS/v1p0/tmp/uvcdat/uvcdat_build/build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 382 vtkXOpenGLRenderWindow (0x27b7f60): Could not find a decent visual

>>> import vcs
>>> x = vcs.init()
>>> x.plot(out[:,:,0])
ERROR: In /export/doutriaux1/build/build/ParaView/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 382
vtkXOpenGLRenderWindow (0x2a1d710): Could not find a decent visual

ERROR: In /export/doutriaux1/build/build/ParaView/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 382
vtkXOpenGLRenderWindow (0x2a1d710): Could not find a decent visual

ERROR: In /export/doutriaux1/build/build/ParaView/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 382
vtkXOpenGLRenderWindow (0x2a1d710): Could not find a decent visual

ERROR: In /export/doutriaux1/build/build/ParaView/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 601
vtkXOpenGLRenderWindow (0x2a1d710): GLX not found.  Aborting.

[oceanonly:07062] *** Process received signal ***
[oceanonly:07062] Signal: Aborted (6)
[oceanonly:07062] Signal code:  (-6)
[oceanonly:07062] [ 0] /lib64/libpthread.so.0() [0x3df340f710]
[oceanonly:07062] [ 1] /lib64/libc.so.6(gsignal+0x35) [0x3df3032625]
[oceanonly:07062] [ 2] /lib64/libc.so.6(abort+0x175) [0x3df3033e05]
[oceanonly:07062] [ 3] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN22vtkXOpenGLRenderWindow13CreateAWindowEv+0x992) [0x7f390e750336]
[oceanonly:07062] [ 4] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN22vtkXOpenGLRenderWindow16WindowInitializeEv+0x25) [0x7f390e751747]
[oceanonly:07062] [ 5] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN22vtkXOpenGLRenderWindow10InitializeEv+0x43) [0x7f390e75181b]
[oceanonly:07062] [ 6] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN22vtkXOpenGLRenderWindow5StartEv+0x25) [0x7f390e751c61]
[oceanonly:07062] [ 7] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN26vtkXRenderWindowInteractor10InitializeEv+0xcd6) [0x7f390e74284c]
[oceanonly:07062] [ 8] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingCore-pv4.1.so.1(_ZN15vtkRenderWindow6RenderEv+0x29f) [0x7f3911a6341f]
[oceanonly:07062] [ 9] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN22vtkXOpenGLRenderWindow6RenderEv+0x7d) [0x7f390e754421]
[oceanonly:07062] [10] /usr/local/uvcdat/2015-02-25/Externals/lib/paraview-4.1/libvtkRenderingOpenGLPython27D-pv4.1.so.1(+0x9c2a6) [0x7f390eb302a6]
[oceanonly:07062] [11] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5a40) [0x7f3940845b20]
[oceanonly:07062] [12] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e) [0x7f394084763e]
[oceanonly:07062] [13] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(+0x778a8) [0x7f39407c58a8]
[oceanonly:07062] [14] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7f39407962c3]
[oceanonly:07062] [15] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4145) [0x7f3940844225]
[oceanonly:07062] [16] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e) [0x7f394084763e]
[oceanonly:07062] [17] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97) [0x7f3940845c77]
[oceanonly:07062] [18] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e) [0x7f394084763e]
[oceanonly:07062] [19] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(+0x778a8) [0x7f39407c58a8]
[oceanonly:07062] [20] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7f39407962c3]
[oceanonly:07062] [21] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4145) [0x7f3940844225]
[oceanonly:07062] [22] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e) [0x7f394084763e]
[oceanonly:07062] [23] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97) [0x7f3940845c77]
[oceanonly:07062] [24] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5eeb) [0x7f3940845fcb]
[oceanonly:07062] [25] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e) [0x7f394084763e]
[oceanonly:07062] [26] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97) [0x7f3940845c77]
[oceanonly:07062] [27] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e) [0x7f394084763e]
[oceanonly:07062] [28] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(+0x778a8) [0x7f39407c58a8]
[oceanonly:07062] [29] /usr/local/uvcdat/2015-02-25/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7f39407962c3]
[oceanonly:07062] *** End of error message ***
doutriaux1 commented 9 years ago

@aashish24 @dlonie why is it looking into my build directory? I think that's the reason the error, I yanked my build directory.

alliepiper commented 9 years ago

The error message strings are compiled in at build time -- it's not actually trying to access anything there, it's just a hint as to which file has the code that's failing.

This particular error is printed out when the GL installation doesn't include the GLX extensions in an X window environment (GLX not found. Aborting.). Check to see if there are any GLX packages available on this platform that are missing.

durack1 commented 9 years ago

@dlonie how would I check to see which GLX packages are missing?

alliepiper commented 9 years ago

You have to check your package manager, which varies among linux distributions.

durack1 commented 9 years ago

@dlonie if nothing has changed with packages installed (which I assume is the case in the gfdl-public1 machine above) is there anything else that would trigger this problem?

alliepiper commented 9 years ago

It's hard to say. Are there any references to GLX in the Xorg log (usually at /var/log/Xorg.0.log)? That should log glx loading.

doutriaux1 commented 9 years ago

@durack1 we know tony rebuilt oceanonly a few times so that's probably the issue there. Can you try to rebuild at gfdl and see what happens please? They might have tweaked a few things there as well.

durack1 commented 9 years ago

@doutriaux1 I will test at GFDL, however am currently locked out.. So am awaiting a password reset..

alliepiper commented 9 years ago

Again, it's not actually trying to access those files. The messages are just static strings compiled into the program at build time to provide a hint to developers as to where the errors are coming from.

doutriaux1 commented 9 years ago

@durack1 as @dlonie explained these are just the error message to hep you debug. They point to where the sources used to compile where. Now if they're gone it doesn't matter for runtime.

durack1 commented 9 years ago

@dlonie @doutriaux1 apologies my mistake.. Will report once I have access..

aashish24 commented 9 years ago

@durack1 does this mache uses X?

durack1 commented 9 years ago

@aashish24 I'm still locked out, but would be happy to provide some diagnostics when I'm back in - want to drop a couple of commands you'd like to see the output of here?

durack1 commented 9 years ago

@dlonie @aashish24 there didn't appear any GLX references in the Xorg log:

public1:/home/p1d/PCMDI_METRICS/test> python portrait-3obs.py 
ERROR: In /home/p1d/PCMDI_METRICS/v1p0/tmp/uvcdat/uvcdat_build/build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 530
vtkXOpenGLRenderWindow (0x1f3e2f0): bad X server connection. DISPLAY=Abort
public1:/home/p1d/PCMDI_METRICS/test> tail -n 30 /var/log/Xorg.0.log
[  1850.394] (**) Macintosh mouse button emulation: always reports core events
[  1850.394] (**) evdev: Macintosh mouse button emulation: Device: "/dev/input/event1"
[  1850.403] (--) evdev: Macintosh mouse button emulation: Vendor 0x1 Product 0x1
[  1850.403] (--) evdev: Macintosh mouse button emulation: Found 3 mouse buttons
[  1850.403] (--) evdev: Macintosh mouse button emulation: Found relative axes
[  1850.403] (--) evdev: Macintosh mouse button emulation: Found x and y relative axes
[  1850.403] (II) evdev: Macintosh mouse button emulation: Configuring as mouse
[  1850.403] (**) evdev: Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
[  1850.403] (**) evdev: Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[  1850.403] (**) Option "config_info" "hal:/org/freedesktop/Hal/devices/computer_logicaldev_input_0"
[  1850.403] (II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE, id 7)
[  1850.403] (II) evdev: Macintosh mouse button emulation: initialized for relative axes.
[  1850.403] (**) Macintosh mouse button emulation: (accel) keeping acceleration scheme 1
[  1850.403] (**) Macintosh mouse button emulation: (accel) acceleration profile 0
[  1850.403] (**) Macintosh mouse button emulation: (accel) acceleration factor: 2.000
[  1850.403] (**) Macintosh mouse button emulation: (accel) acceleration threshold: 4
[  1850.403] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 1 connected from local host ( uid=0 gid=0 pid=2488 )
  Auth name: MIT-MAGIC-COOKIE-1 ID: 240
[  1850.442] (II) MGA(0): VESA VBE DDC read failed
[  1850.558] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 connected from local host ( uid=0 gid=0 pid=2497 )
  Auth name: MIT-MAGIC-COOKIE-1 ID: 240
[  1850.559] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 disconnected
[  1850.599] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 connected from local host ( uid=0 gid=0 pid=2499 )
  Auth name: MIT-MAGIC-COOKIE-1 ID: 240
[  1850.683] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 disconnected
[  1850.711] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 connected from local host ( uid=0 gid=0 pid=2502 )
  Auth name: MIT-MAGIC-COOKIE-1 ID: 240
[  1850.725] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 disconnected
[  1851.180] AUDIT: Sat Feb 28 13:35:40 2015: 2492: client 2 connected from local host ( uid=0 gid=0 pid=2506 )
  Auth name: MIT-MAGIC-COOKIE-1 ID: 240
public1:/home/p1d/PCMDI_METRICS/test> date
Thu Mar 19 03:25:01 EDT 2015
public1:/home/p1d/PCMDI_METRICS/test> uname -a
Linux public1 2.6.32-504.8.1.el6.x86_64 #1 SMP Fri Dec 19 12:09:25 EST 2014 x86_64 x86_64 x86_64 GNU/Linux

What other diagnostics would be useful? The connection to this machine uses ssh -Y

alliepiper commented 9 years ago

@durack1 Just making sure -- I see you looked at the last 30 lines, but did you look through the entire file? The xorg log gets cleared every time X starts, and the GLX bits would be towards the beginning of the file when the server is starting up.

aashish24 commented 9 years ago

@durack1 can you share the content of entire file with us?

durack1 commented 9 years ago

@dlonie @aashish24 apologies for holding things up here, take a peek at:

https://gist.github.com/durack1/076e7294f7d7201ff7c0

durack1 commented 9 years ago

@dlonie @aashish24 is anything clearly evident in the log? It seems this issue has now been replicated on two independent systems..

alliepiper commented 9 years ago

I'm not terribly familiar with xorg's inner workings, but this would seem to be a configuration issue in computer's xorg server. Certain bits needed for rendering appear to be disabled or not installed.

@aashish24 Do you have any ideas?

durack1 commented 9 years ago

@dlonie @aashish24 I've just rebuilt UV-CDAT assuming that the issue was caused by some library being updated underneath the existing UV-CDAT installation.. Well it appears that assumption is wrong, I've just rebuilt and get the same error:

public1:/home/p1d/PCMDI_METRICS/test> python portrait-3obs.py
ERROR: In /home/p1d/PCMDI_METRICS/v1p0p0/tmp/uvcdat/uvcdat_build/build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 382
vtkXOpenGLRenderWindow (0x2e23ff0): Could not find a decent visual

Segmentation fault

So my assumption is this is a real issue somewhere in the VTK build.. What else do you folks need from me to diagnose what this issue is and figure out a resolution?

aashish24 commented 9 years ago

@durack1 what platform / OS / you are using?

durack1 commented 9 years ago

@aashish24 it's redhat 6.6:

public1:/home/p1d/PCMDI_METRICS/test> uname -a
Linux public1 2.6.32-504.8.1.el6.x86_64 #1 SMP Fri Dec 19 12:09:25 EST 2014 x86_64 x86_64 x86_64 GNU/Linux
public1:/home/p1d/PCMDI_METRICS/test> more /etc/redhat-release
Red Hat Enterprise Linux Workstation release 6.6 (Santiago)
aashish24 commented 9 years ago

thanks. and what graphics card it has. Its not VM is it? Is it connected to a display?

durack1 commented 9 years ago

It's an active ssh connection (I've enabled X11 forwarding using the -X option)

durack1 commented 9 years ago

@aashish24 @dlonie I'd note that the issue is with builds tagged 2.1.0 release - are there any updates in the UV-CDAT master that would fix this issue? Or VTK updates which have been implemented in preparation of 2.2.0 tagging?

aashish24 commented 9 years ago

Hi @durack1 this is not really a uvcdat/vtk issue but rather a system / opengl issue. This has something to do with the SSH forwarding. Did you try running glxgears on the same setup? Does that work?

durack1 commented 9 years ago

@aashish24 nope, glxgears doesn't work on either of the redhat 6.6 machines that I've hit this problem on.. I've just issued a reboot for the machine I have privileges on and will re-test again once it's back up.. I seem to recall that some GL updates have come down the redhat update pipeline in the last month or so..

aashish24 commented 9 years ago

Okay which confirms my suspicion that it is a system problem. If glxgears works then UV-CDAT will work as well. Using offscreen option wouldnot work for you as you want rendering to be happening on the client side? Basically its a X forwarding issue that you are dealing with.

doutriaux1 commented 9 years ago

@aashish24 by offscreen I think @durack1 meant mesa. This should work right?

durack1 commented 9 years ago

@aashish24 @doutriaux1 @dlonie I've also opened an issue https://github.com/TigerVNC/tigervnc/issues/162 just to see if someone else has discovered problems with the redhat openGL..

aashish24 commented 9 years ago

sure, I understood that part but I don't think that will help unless you want to dump the image on the server side.

aashish24 commented 9 years ago

I kind of take it back. I don't know what will happen in that case

durack1 commented 9 years ago

@aashish24 the intention here is to write a png file on the server - so there is no need to visualise anything, just write to the file. This is actually what the current script is trying to do, I never see what I'm trying to plot before opening the png using a graphics viewer

aashish24 commented 9 years ago

okay, try with the mesa option and see if that works for you.

durack1 commented 9 years ago

@aashish24 @dlonie @doutriaux1 apologies for dragging this along.. It appears that a reinstallation of a bunch of key packages (mesa-libGL, vncserver etc) has now solved the issue - so it does appear to have been a local client/X11 forwarding issue, rather than something problematic with the VTK install.

Sorry for the run around with this - closing

And just for reference: https://access.redhat.com/solutions/56301

aashish24 commented 9 years ago

Thanks for the update! Appreciate it.

ThomasMaxwell commented 9 years ago

Wen attempting to start up a recently build version of UVCDAT (from yesterday's master) I get the following error. Is there a fix for this?:

IOError: [Errno 2] No such file or directory: ‘…/install/Library/Frameworks/Python.framework/Versions/2.7/share/uvcmetrics.json'

durack1 commented 9 years ago

@ThomasMaxwell I'm not sure this problem is relevant to this closed issue (#1134) - maybe it's worth opening a new issue..

Additionally @painter1 might know more about the uvcmetrics stuff