glGetString fails.... but not always

OpenGL OpenGL: Advanced Coding
1

Right.

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? :confused:

2

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?

3

Are you using multiple threads ?
You should call wglmakecurrent to use commands on the current thread

4

I agree, at this point I’m leaning toward some kind of memory stomping problem, or a bug in NVidia’s GL libraries.

In the shared-link case glGetString returns NULL even immediately after the context is created and made current.

In the static-link case, it returns the correct string at that point.

5

Nope, it’s a single-threaded monolithic monster of doom.

6

is the program MFC based ? If so you are probably passing the wrong HDC for makecurrent

7

This is in Linux-land. :slight_smile:

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.

8

Are you sure that its returning this garbage? Ie, isnt this the value of that variable from before glGetIntegerv?

It looks like your GL functions are dispatched to empty implementation if that’s the case. How do you obtain pointers to these functions?

9

Solved! (I think.)

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:

Thanks for your suggestions everyone.