Bug 36761

Are you sure about this?  The code is as follows:

static void
get_attached_shaders(struct gl_context *ctx, GLuint program, GLsizei maxCount,
                     GLsizei *count, GLuint *obj)
{
   struct gl_shader_program *shProg =
      _mesa_lookup_shader_program_err(ctx, program, "glGetAttachedShaders");
   if (shProg) {
      GLuint i;
      for (i = 0; i < (GLuint) maxCount && i < shProg->NumShaders; i++) {
         obj[i] = shProg->Shaders[i]->Name;
      }
      if (count)
         *count = i;
   }
}

The maxCount parameter is used to limit the loop.

I also hacked a demo program to test this and didn't see any problem.

Yes, gdb points the segfault to this line in Irrlicht source:
Driver->extGlDeleteObject(shaders[i]);
Which segfaults because it's trying to access the array beyond 8.

To check this I added a printf right after this call:
Driver->extGlGetAttachedObjects(Program, 8, &count, shaders);

And indeed, count is a random value above 32k (32516 in my latest test).


It's possible this is an Irrlicht bug as well, but GetAttachedObjects returns something huge in the count param.

Perhaps 'program' doesn't name an existing shader program.  In that case the count parameter will not get set.  I'll have to check the spec to see what's supposed to be done when 'program' is invalid.

You're right, when I set count = 0 before the call to GetAttachedObjects, it stays 0.

However, this is the only shader program created, and it's very much working (I can see the effects). It's also not deleted before the call, so it should be valid.

Can you call glGetError() before and after the call to glGetAttachedObjects() to see if GL_INVALID_VALUE is generated?  That's what Mesa and NVIDIA both do (and the count parameter is untouched).

Otherwise, can you step into get_attached_shaders() and examine shProg?

glGetError both before and after returns 0.

Sorry for wasting your time, stepping into shaderapi.c showed that this is a bug in Irrlicht, not in mesa. Irr was releasing the shaders _after_ destroying the glx context.