With the current SVN version, I get a segmentation fault on Ubuntu 10.04
and 10.10, both using the free ATI drivers. The code in question is in
lib/client/glXWindow.cpp:
63 // Early glxew init to have function pointers for init code
64 Display* display = getXDisplay();
65 glXMakeCurrent( display, None, 0 );
66 glxewInit();
If if remove the glxewInit() call, then the examples (eqHello and eqPly)
work fine.
It is probably not ok to just remove the glxewInit() call, and maybe
this is a problem of the Xorg/Mesa/ATI driver stack instead of
Equalizer, but I'm not sure about this.
Does anybody have an idea what's going on?
Martin
--
Computer Graphics and Multimedia Systems Group
University of Siegen, Germany
http://www.cg.informatik.uni-siegen.de/
> Does anybody have an idea what's going on?
Are you crashing in glxewInit, or sometimes later? I can't reproduce it here due to the lack of an ATI card, but maybe somebody from the community can help out. Debugging glew can be guesswork at times, since things are hidden in macros.
Cheers,
Stefan.
_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Hey,
I ran into this issue myself. It appears that the ati drivers expect to be able get the current X11 display when you make certain glx calls. The backtrace looks like it travels through glew into the ati driver (free here), and then the ati driver tried to contact the X11 server using the X11 display connection in the GL context. Since no GL context exists, the X11 display connection is null, thus a null dereference happens and it all blows up. I believe the issue is in the driver, not eq. As a workaround, I think you could create a temporary GL context that would allow for the driver to execute its queries.
Hope that helps,
Matthew
Backtrace:
#0 0x00007f978a475d18 in XQueryExtension () from /usr/lib/libX11.so.6
#1 0x00007f978a46a0af in XInitExtension () from /usr/lib/libX11.so.6
#2 0x00007f978a235712 in XextAddDisplay () from /usr/lib/libXext.so.6
#3 0x00007f978cc4c896 in ?? () from /usr/lib/libGL.so.1
#4 0x00007f978cc47b39 in glXQueryVersion () from /usr/lib/libGL.so.1
#5 0x00007f978a006aa3 in glxewContextInit () from /usr/lib/libGLEWmx.so.1.5
#6 0x00007f978d0ff05c in eq::GLXWindow::configInit (this=0x1fb8dc0) at /home/matthew/pkg_src/Equalizer-svn/lib/client/glXWindow.cpp:66
#7 0x00007f978ea260b9 in Helios::Server::Equalizer::WindowClient::configInitOSWindow (this=0x1fb7940, initID=16)
at /home/matthew/Job/vidalab.git/Helios/server/equalizer/windowclient.cpp:49
#8 0x00007f978d0ed88f in eq::Window::configInit (this=0x1fb7940, initID=16) at /home/matthew/pkg_src/Equalizer-svn/lib/client/window.cpp:332
#9 0x00007f978ea25f9b in Helios::Server::Equalizer::WindowClient::configInit (this=0x1fb7940, initID=16)
at /home/matthew/Job/vidalab.git/Helios/server/equalizer/windowclient.cpp:32
#10 0x00007f978d0eedd7 in eq::Window::_cmdConfigInit (this=0x1fb7940, command=...) at /home/matthew/pkg_src/Equalizer-svn/lib/client/window.cpp:646
#11 0x00007f978d12a3a6 in eq::net::CommandFunc<eq::net::Dispatcher>::operator() (this=0x1fb8880, command=...)
at /home/matthew/pkg_src/Equalizer-svn/build.cmake/include/eq/net/../../../../lib/net/commandFunc.h:48
#12 0x00007f978d129e23 in eq::net::Dispatcher::invokeCommand (this=0x1fb7940, command=...) at /home/matthew/pkg_src/Equalizer-svn/lib/net/dispatcher.cpp:121
#13 0x00007f978d16df69 in eq::net::Session::_invokeObjectCommand (this=0x1f96a20, command=...) at /home/matthew/pkg_src/Equalizer-svn/lib/net/session.cpp:709
#14 0x00007f978d16dd77 in eq::net::Session::invokeCommand (this=0x1f96a20, command=...) at /home/matthew/pkg_src/Equalizer-svn/lib/net/session.cpp:692
#15 0x00007f978d0c7800 in eq::Pipe::_runThread (this=0x1fa93d0) at /home/matthew/pkg_src/Equalizer-svn/lib/client/pipe.cpp:250
#16 0x00007f978d0ce2f6 in eq::Pipe::PipeThread::run (this=0x1fa8090) at /home/matthew/pkg_src/Equalizer-svn/lib/client/pipe.h:387
#17 0x00007f978d0467a8 in eq::base::Thread::_runChild (this=0x1fa8090) at /home/matthew/pkg_src/Equalizer-svn/lib/base/thread.cpp:116
#18 0x00007f978d0464c2 in eq::base::Thread::runChild (arg=0x1fa8090) at /home/matthew/pkg_src/Equalizer-svn/lib/base/thread.cpp:91
#19 0x00007f978b5238ba in start_thread (arg=<value optimized out>) at pthread_create.c:300
#20 0x00007f978b80802d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#21 0x0000000000000000 in ?? ()
> I ran into this issue myself. It appears that the ati drivers expect to be able get the current X11 display when you make certain glx calls. The backtrace looks like it travels through glew into the ati driver (free here), and then the ati driver tried to contact the X11 server using the X11 display connection in the GL context. Since no GL context exists, the X11 display connection is null, thus a null dereference happens and it all blows up. I believe the issue is in the driver, not eq. As a workaround, I think you could create a temporary GL context that would allow for the driver to execute its queries.
It seems then that the GLXEW initialization should happen like the WGLEW initialization in WGLPipe: open temp context, query extensions, delete temp context. That also means moving the GLXEWContext to GLXPipe, which makes the whole construct more symmetric.
Any volunteers for this task?
> It seems then that the GLXEW initialization should happen like the WGLEW initialization in WGLPipe: open temp context, query extensions, delete temp context. That also means moving the GLXEWContext to GLXPipe, which makes the whole construct more symmetric.
Revision 5293 fixes this, along with GLXEW on Mac OS X:
http://equalizer.svn.sourceforge.net/equalizer/?rev=5293&view=rev
Matthew - Can you test if this works for you?
Sorry for the delay, I was only working on a project involving Eq during the summer, and I wasn't keeping it up to date with the latest Eq in svn. I got the application updated now recently, and I can confirm that GLXEW now works both on the open and closed source driver. It also works fine with your other changes under ATI with the closed source driver. It appears to work with the open source driver, but my application uses opengl 3.x features, so I can't verify it work 100%. The gl context is created however.
Matthew