Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have installed the lastest version of VirtualGL 2.2.90 (2.3beta1) and TurboVNC 1.0.2 and followed the User Guide to install and configure VirtualGL and TurboVNC.
But whenever I start an OpenGL application like glxspheres64 I get a segementation fault. My server is running debian wheezy, kernel 3.0.0-1-amd64 and a AMD Radeon HD 6300 with Catalyst 11.7.
Enclosed you can find some output from glxinfo and a strace from the segmentation fault:
glxinfo with DISPLAY=:0
View at pastebin: http://pastebin.com/9yz7My0d
glxinfo with DISPLAY=:1 (TurboVNC)
The "GLX" missing on display ":1" is obvious but why is the segementation fault?
View at pastebin: http://pastebin.com/bLiZcMyq
strace "_vglrun /opt/VirtualGL/bin/glxspheres64"glxspheres64 with DISPLAY=:1_
I have no idea why and where the segmentaion fault occours :-(
View at pastebin: http://pastebin.com/VBmFyjTN
PS: I have configured my "Client" machine a Mac Mini (GPU is a Nvidia 9400) running Ubuntu 11.04 and have no trouble running the above testcases.
Thanks for any hints!
There is a well-known bug in the Catalyst drivers that causes them to seg fault when sending GLX commands to a remote display. This may be due to a mismatch in the GLX client and server implementations (that is, it may be the case that it doesn't seg fault if the remote display also has the Catalyst drivers, but this is unknown.)
Thus, expected behavior when using the Catalyst drivers:
(1) Running GLXspheres to a remote display will seg fault.
(2) vglrun GLXspheres to a remote display (using the VGL Transport) will seg fault if the remote display supports GLX. This is because VirtualGL uses glXChooseVisual() to probe the remote display's ability to display stereo.
However, TurboVNC doesn't support GLX, so I have no idea why the seg faults would be occurring with that display.
strace does me no good whatsoever, because the bug is not in the O/S. It's in the drivers. What I really need to see is the output of 'vglrun +tr /opt/VirtualGL/bin/glxspheres64' and then a stack trace from the seg fault.
I am not shure how to get a proper stack trace from the seg fault. What I have done so far is getting the backtrace from the the core file using gdb. But without debugging symbols it is quite useless for you. Or am I wrong?
The output is at pastebin agein:
vglrun +tr glxspheres64: http://pastebin.com/ScmYZxXL
gdb glxsperes64: http://pastebin.com/wEkAQa0X
Sorry I am no expert in debugging right now :-) If you need better or more information let me know how and I will provide you with everything you need.
Thanks for your help and time.
even though I haven´t heard from you again my problems went away after Debian delivered ATI Catalyst 11.8 in testing.
Everything is working now vglrun + vglclient and also vglrun + TurboVNC.