vtkXOpenGLRenderWindow: Could not find a decent visual #1134
Comments
|
@aashish24 @dlonie why is it looking into my build directory? I think that's the reason the error, I yanked my build directory. |
|
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 ( |
|
@dlonie how would I check to see which GLX packages are missing? |
|
You have to check your package manager, which varies among linux distributions. |
|
@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? |
|
It's hard to say. Are there any references to GLX in the Xorg log (usually at |
|
@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. |
|
@doutriaux1 I will test at GFDL, however am currently locked out.. So am awaiting a password reset.. |
|
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. |
|
@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. |
|
@dlonie @doutriaux1 apologies my mistake.. Will report once I have access.. |
|
@durack1 does this mache uses X? |
|
@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? |
|
@dlonie @aashish24 there didn't appear any GLX references in the Xorg log: What other diagnostics would be useful? The connection to this machine uses |
|
@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. |
|
@durack1 can you share the content of entire file with us? |
|
@dlonie @aashish24 apologies for holding things up here, take a peek at: https://gist.github.com/durack1/076e7294f7d7201ff7c0 |
|
@dlonie @aashish24 is anything clearly evident in the log? It seems this issue has now been replicated on two independent systems.. |
|
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? |
|
@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: 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? |
|
@durack1 what platform / OS / you are using? |
|
@aashish24 it's redhat 6.6: |
|
thanks. and what graphics card it has. Its not VM is it? Is it connected to a display? |
|
It's an active ssh connection (I've enabled X11 forwarding using the -X option) |
|
@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? |
|
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? |
|
@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.. |
|
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. |
|
@aashish24 by offscreen I think @durack1 meant mesa. This should work right? |
|
@aashish24 @doutriaux1 @dlonie I've also opened an issue TigerVNC/tigervnc#162 just to see if someone else has discovered problems with the redhat openGL.. |
|
sure, I understood that part but I don't think that will help unless you want to dump the image on the server side. |
|
I kind of take it back. I don't know what will happen in that case |
|
@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 |
|
okay, try with the mesa option and see if that works for you. |
|
@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: |
|
Thanks for the update! Appreciate it. |
|
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' |
|
@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 |
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 visualgfdl-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 visualThe text was updated successfully, but these errors were encountered: