On Fri, Apr 23, 2010 at 8:19 PM, DRC <[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]>> 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]>>> 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]>>
> >     >     > 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
>



-- 
http://www.shreekumar.in/
------------------------------------------------------------------------------
_______________________________________________
VirtualGL-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Reply via email to