Segmentation fault using glGetString() with pthreads under linux

Question

I'm trying to load textures in a background thread to help speed up my application. The stack we are using is C/C++ on Linux, compiling with gcc. We're using OpenGL, GLUT and GLEW. We have been using libSOIL for texture loading. Ultimately, launching texture loads with libSOIL fails because it encounters a glGetString() call that causes a segfault. Trying to narrow down the problem, I wrote a very simple OpenGL application that reproduces the behavior. The below code sample shouldn't "do anything," but it also shouldn't segfault. If I knew why it did, I could in theory rework libSOIL so that it would behave in a pthreaded environment. ``` void *glPthreadTest( void* arg ) { glGetString( GL_EXTENSIONS ); //SIGSEGV return NULL; } int main( int argc, char **argv ) { glutInit( &argc, argv ); glutInitDisplayMode( GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH ); glewInit(); glGetString( GL_EXTENSIONS ); // Does not cause SIGSEGV pthread_t id; if (pthread_create( &id, NULL, glPthreadTest, (void*)NULL…

Accepted Answer

In order for any OpenGL call to operate properly, it requires an OpenGL context. Contexts are created using a window-system binding call (like `wglCreateContext` or similar). After creating a context, it needs to be "made current", which means associating the context with the current thread of execution. This is accomplished with another window-system specific call (like `wglMakeCurrent` for Microsoft Windows, or `glXMakeCurrent` for X Windows). GLUT abstracts all of that complexity away from you, doing all of those operations when you call `glutCreateWindow`.

Now, an important rule to know is that only a single OpenGL context can be current to a thread of execution at any one time. So, in the OP's original example, if she/he could make the context current in the Pthread they created, then the context would be lost in the main thread. The way to keep all this consistent is to only use a single context in a single thread. (It's possible to have OpenGL contexts share data, but that's neither exposed by GLUT, nor possible without using the window-system context creation calls).

In your case, it's likely that GLUT doesn't allow access to what you really need (i.e., the OpenGL context), to make it current in the other thread. You'd need to create and manage OpenGL contexts yourself.

Segmentation fault using glGetString() with pthreads under linux

Solution

Problem