AnsweredAssumed Answered

GL_PROGRAM_BINARY_LENGTH crash

Question asked by viciious on Jun 4, 2014

Hello,

 

I've recently run into a nasty crash in glGetProgramiv that queries for program's binary length. The application I'm working tries to cache binary representation of all compiled and linked programs to speed up the startup process the next time the application is run. The crash appears to be somewhat random and looks like a race condition to me (just a random guess).

 

OS: Windows 7

Driver version: 14.4

GPU: Radeon HD 5770

 

Here's the relevant part of code:

static void *RP_GetProgramBinary( int elem, int *format, unsigned *length )
{
     void *binary;
     glsl_program_t *program = r_glslprograms + elem - 1;
     GLenum GLFormat;
     GLint GLlength;
     GLint linked = 0;

     if( !glConfig.ext.get_program_binary ) {
          return NULL;
     }
     if( !program->object ) {
          return NULL;
     }

     qglGetObjectParameterivARB( program->object, GL_OBJECT_LINK_STATUS_ARB, &linked );
     if( !linked ) {
          return NULL;
     }

     qglGetProgramiv( program->object, GL_PROGRAM_BINARY_LENGTH, &GLlength );
     if( !GLlength ) {
          return NULL;
     }

     binary = R_Malloc( GLlength );
     qglGetProgramBinary( program->object, GLlength, NULL, &GLFormat, binary );

     *format = GLFormat;
     *length = GLlength;

     return binary;
}

 

Screenshot of the stacktrace: http://imgur.com/OFoIKr7

 

The error message is:

Unhandled exception at 0x68fff0d0 in warsow_x86.exe: 0xC0000005: Access violation writing location 0x0000000c.

 

glUseProgramObjectARB is called prior to the whole caching process.

 

Dunno whether's that's important or not that there's a second thread running with its own GL context that manages asynchronous loading of textures. Programs are compiled and run from the main thread though.

Outcomes