Can you try running with "vglrun -nodl"? If that doesn't fix the issue, then please run with "vglrun +tr" and send me the output.
What seems to be happening is that the address of the "real" version of glXGetFBConfigs() is not being set somehow. On 4/23/10 11:36 AM, Shree Kumar wrote: > > On Fri, Apr 23, 2010 at 8:19 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > Stack trace? Is the seg fault occurring in VirtualGL? > > Here's the stack trace for now. Doesn't show which library it is in. > Long time since I looked at a stack trace now! Is that a null pointer on > top - hmm ? > ------------- > Core was generated by `eqPly -m /home/shree/happy.ply'. > Program terminated with signal 11, Segmentation fault. > #0 0x0000000000000000 in ?? () > (gdb) where > #0 0x0000000000000000 in ?? () > #1 0x00007f88caa7c992 in eq::GLXWindow::configInitGLXPBuffer > (this=0x1d1cd50, visualInfo=0x1d1d6b0) at client/glXWindow.cpp:475 > #2 0x00007f88caa7baac in eq::GLXWindow::configInitGLXDrawable > (this=0x1d1cd50, visualInfo=0x1d1d6b0) at client/glXWindow.cpp:298 > #3 0x00007f88caa7a54f in eq::GLXWindow::configInit (this=0x1d1cd50) at > client/glXWindow.cpp:68 > #4 0x00007f88caa5067b in eq::Window::configInitOSWindow > (this=0x1c6cfa0, initID=74) at client/window.cpp:543 > #5 0x000000000045c9e4 in eqPly::Window::configInitOSWindow > (this=0x1c6cfa0, initID=74) at window.cpp:37 > #6 0x00007f88caa50406 in eq::Window::configInit (this=0x1c6cfa0, > initID=74) at client/window.cpp:502 > #7 0x00007f88caa51a8f in eq::Window::_cmdConfigInit (this=0x1c6cfa0, > command=...) at client/window.cpp:826 > #8 0x00007f88ca9579ee in > eq::net::CommandFunc<eq::net::Dispatcher>::operator() (this=0x1c6d4d0, > command=...) at .././build/Linux/include/eq/net/commandFunc.h:50 > #9 0x00007f88ca957421 in eq::net::Dispatcher::invokeCommand > (this=0x1c6cfa0, command=...) at net/dispatcher.cpp:122 > #10 0x00007f88ca9ac1bb in eq::net::Session::_invokeObjectCommand > (this=0x7f88c00023a0, command=...) at net/session.cpp:614 > #11 0x00007f88ca9abbaa in eq::net::Session::invokeCommand > (this=0x7f88c00023a0, command=...) at net/session.cpp:576 > #12 0x00007f88caa2c71b in eq::Pipe::_runThread (this=0x7f88c000ea20) at > client/pipe.cpp:328 > #13 0x00007f88caa317d6 in eq::Pipe::PipeThread::run > (this=0x7f88c000e7f0) at client/pipe.h:476 > #14 0x00007f88ca9389a0 in eq::base::Thread::_runChild > (this=0x7f88c000e7f0) at base/thread.cpp:132 > #15 0x00007f88ca938818 in eq::base::Thread::runChild > (arg=0x7f88c000e7f0) at base/thread.cpp:111 > #16 0x00007f88ca59ea04 in start_thread () from /lib/libpthread.so.0 > #17 0x00007f88c942780d in clone () from /lib/libc.so.6 > #18 0x0000000000000000 in ?? () > (gdb) up > #1 0x00007f88caa7c992 in eq::GLXWindow::configInitGLXPBuffer > (this=0x1d1cd50, visualInfo=0x1d1d6b0) at client/glXWindow.cpp:475 > 475 GLXFBConfig* configs = glXGetFBConfigs( display, screen, > &nConfigs ); > (gdb) > > > On 4/23/10 9:40 AM, Shree Kumar wrote: > > Thanks, DRC ! VirtualGL/TurboVNC make VizStack useful too :-) > > > > I have been trying this out. pbdemo works, no problems there. Other > > than the fact that it overwrote another PPM file ;-) > > > > So I look deeper into the source code of the equalizer library( > > http://www.equalizergraphics.com/) ; I'm running > > the eqPly program now. > > > > The app does multiple calls to glXChooseVisual, some of which return > > NULL. But the last few don't. > > > > However, the segfault happens in some code which looks like : > > > > int nConfigs = 0; > > GLXFBConfig * configs = glXGetFBConfigs(display, screen, > &nConfigs); <-- > > segfault ! > > > > The "display" value is OK, and "screen" is 0. I'm still debugging > with the > > source code, but any hints would be very useful ! > > > > Thanks > > -- Shree > > > > On Fri, Apr 23, 2010 at 7:04 PM, DRC > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > Oops, I apparently glazed over that part of the original > message. :) > > VizStack looks very cool. > > > > If pbdemo works, then please send the source code for the app > that is > > failing, and I'll try it out here. That warning message from > VirtualGL > > is printed in glXChooseVisual() and is typically caused by one > of three > > things: > > > > -- The 2D X server doesn't have a 24-bit visual available > > -- The 3D X server (:15 in your case) doesn't have a 24-bit or > 32-bit FB > > config available > > -- The 3D X server doesn't have an FB config available that > supports > > Pbuffers > > > > This warning message is printed whenever VirtualGL can't obtain an > > appropriate 24-bit or 32-bit Pbuffer-enabled FB config to map > to the > > visual that the app is requesting. The warning basically > says-- the > > application is probably about to print an error message and > fail. In > > your case, the application appears to be subsequently seg > faulting, > > which isn't good. It may not be properly checking for a NULL > return > > value from glXChooseVisual(). > > > > On 4/22/10 10:31 PM, Shree Kumar wrote: > > > > > > Yes, I have set VGL_DISPLAY before using vglrun. > > > > > > I'm on a 6 GPU box. The piece of software I'm writing (VizStack, > > mentioned > > > below) dynamically manages the X servers. I see some mails > in the list > > > asking about how to use VirtualGL with multiple GPUs. VizStack > > will meet > > > their needs on single nodes as well as on cluster of nodes. > > > > > > VizStack maintains pools of X servers, so I end up with :15 ! > > > > > > I will try running mesademos/pbdemo.c. > > > > > > Thanks > > > -- Shree > > > > > > On Thu, Apr 22, 2010 at 8:33 PM, DRC > > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > > > > > VirtualGL should run fine with applications that use > Pbuffers. > > > mesademos/pbdemo.c in the VirtualGL source tree > demonstrates this. > > > There is apparently something else wrong here. > > > > > > The fact that your 3D X server is :15 is unusual. The 3D X > > server is > > > typically :0.0, although it may be :0.1 or :0.2 if you have > > multiple 3D > > > graphics cards. Did you override the default value of > > VGL_DISPLAY? If > > > so, why did you set it to :15? > > > > > > On 4/22/10 5:38 AM, Shree Kumar wrote: > > > > Hi, > > > > > > > > I've been using TurboVNC/VirtualGL as a remote access > mechanism; > > > we also > > > > provide it as a remote access method with VizStack > > > > (http://www.vizstack.sourceforge.net) > > > > > > > > In my setup, "vglrun glxgears" works fine. However, an > > application > > > which > > > > uses Pbuffers itself fails. e.g. > > > > > > > > > sh...@servergfx:~/equalizer-release-0.9.1/examples/configs$ > > vglrun > > > eqPly > > > > -m ~/happy.ply > > > > [VGL] WARNING: VirtualGL attempted and failed to obtain a > > > Pbuffer-enabled > > > > [VGL] 24-bit visual on the 3D X server :15. If the > > application > > > > [VGL] subsequently fails, then make sure that the 3D X > > server is > > > > configured > > > > [VGL] for 24-bit color and has accelerated 3D drivers > > installed. > > > > Segmentation fault > > > > > sh...@servergfx:~/equalizer-release-0.9.1/examples/configs$ > > > > > > > > In this case, equalizer is trying to create a pbuffer for > > rendering. > > > > > > > > Any hints on what could be going wrong here ? > > > > > > > > Thanks > > > > -- Shree > > > > http://vizstack.sourceforge.net/ > > > > http://www.shreekumar.in/ > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > VirtualGL-Users mailing list > > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > VirtualGL-Users mailing list > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > > > > > > -- > > > http://www.shreekumar.in/ > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > VirtualGL-Users mailing list > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > VirtualGL-Users mailing list > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > -- > > http://www.shreekumar.in/ > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > VirtualGL-Users mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > -- > http://www.shreekumar.in/ > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
