We have an Inventor application at work that we’ve been carrying around since the SGI days. Now, we’ve always compiled our own code into static archives, but as kind of a science project I’m trying to build everything into shared objects instead.
Here’s the problem. When I link this app against our static libraries, it works fine, every time. When I link it against the shared objects, I get a crash deep in the Open Inventor code; also every time. The cause is that glGetString(<anything>) returns NULL. Google tells me that this is usually caused by not having a valid context, but I’m reasonably sure I have one. At the point of the failure, glXGetCurrentContext() returns a pointer (which I can see get created by the Inventor code). And after glGetString() returns NULL, glGetError() says there’s nothing wrong.
I’ve put in a ton of debugging prints, and the output is the same in both cases, except in the crash case, all the glGetString() calls return NULL.
In both cases the same .so GL and Inventor libraries are used – it’s only our local libraries that change.
I’m on a Centos 5.? machine, NVidia Quadro NVS 290 card, and just installed the v290.10 drivers.
Does anyone have an idea on how this is even possible?
Does anyone have an idea on how this is even possible?
When you get things with this level of weirdness happening, I’m guessing heap corruption. Especially since it works with static linking (which would shuffle things around in memory).
What do you get early on in the program if you call glGetString then?
I discovered today that glGetIntegerv is also returning garbage in the failure case. For instance, glGetIntegerv(GL_MAX_LIGHTS) returns a large negative number (-272716322 to be precise) in the crashing version of the application, but 8 in the working version.
Turns out that one of our local libraries required the OSMesa library, which also defines the glGetString and glGetIntegerv functions. I moved OSMesa later in the link command and now it works.
If someone is googling this in the future, the way I discovered it was doing a glXGetProcAddress(“glGetString”). This returned a different pointer than the plain glGetString symbol. And calling the function through the pointer returned by glXGetProcAddress worked. Adding ‘-y glGetString’ to the ld options showed that glGetString was found in libOSMesa.so instead of libGL.so.
That’s a few days off my life I’ll never get back. :mad: