VirtualGL doesn't explicitly load glGenBuffers(), because that isn't a function we interpose. We are just linking librrfaker.so with libGL.so and relying on the dynamic linker to find all of the OpenGL functions for us that we aren't explicitly interposing. I'm not sure how we can be expected to accommodate such bad behavior as an application overriding an OpenGL symbol locally. I don't even understand why that works at all, even without VirtualGL. How does the application not get muldefs when linking with libGL?
Some questions: (1) What happens if librrfaker.so is linked using -Wl,-z,interpose ? (2) Can the glGenBuffers() symbol be successfully loaded at all, perhaps using _glXGetProcAddress()? Or does librrfaker always pick up the application's version? I am really not interested in implementing a symbol loader for every function that some random app decides it wants to override locally. That way lies madness. If there is some way to automatically force librrfaker to always load OpenGL symbols from libGL rather than the app (which is why I asked about -z interpose above), then I'm definitely game to implement that, but otherwise, I think this needs to be pushed back to the Viewperf developers. Viewperf is an open source app, so it's not as if it is immutable. They'd probably accept a patch to fix this on their end, and I could document under "Application Recipes" that certain versions of Viewperf require VGL_READBACK=sync to work properly. On 5/15/14 8:56 PM, Nathan Kidd wrote: > Hi, > > I recently came across this issue in viewperf (from SPEC): > > Viewperf defines a local glGenBuffers function pointer, initializes to > NULL, and then decides since it isn't using VBOs to never initialize to > a real function. Thus with PBOs on by default in VGL now, VGL does > readback, calls glGenBuffers() and gets a SEGV because the pointer is > NULL. > > The most simple patch is add a "&& glGenBuffers" before pbdrawable uses > glGenBuffers) but means the rest of the code can't rely on the > fconfig.readback status. > > The still simple but slightly cleaner (if you'll excuse the type abuse) > fix is to disable PBO readback if glGenBuffers is NULL (check in > fakerconfig.cpp). Patch attached. (I wasn't sure if you cared about > requiring libGL for everything that links with fakerconfig.cpp or not, > hence the dlsym rather than including gl.h) > > An alternate fix, that has the benefit of allowing PBOs with viewperf, > would be to check if the symbol was NULL and dlsym(RTLD_NEXT, > glGenBuffers), plus all the other symbols viewperf NULLs. > > Patch applies to trunk with: > > patch -p1 < 0001-Disable-PBO-use-if-glGenBuffers-is-NULL.patch > > Cheers, > > -Nathan > > P.S. Of course this error points out that the same issue could happen > with *any* symbol that VGL calls directly but the app redefined. I > think the "dlsym all GL functions VGL uses" step is only something to > consider if we see it in practice, but something I'm keeping in the back > of my mind is that google suggests that GLEW in particular seems to have > this paradigm of all extension functions are pointers, and app needs to > initialize after a context is created. Any call that invokes VGL usage > (e.g. glxSwapBuffers) before that GLEW initialization is done in the app > will easily end up the the same SEGV situation. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
