The doc states "It returns in objects as many of the handles of these shader objects as it can, up to a maximum of maxCount.", however, Mesa returns them all at once ignoring the maxcount param. Since in my test the array is GLhandleARB shaders[8], and Mesa returns over 32k handles, I get nice segfaults. r600g Mesa 7.11-devel (git-608a4a1) This can be seen in Irrlicht example 10, when enabling glsl shaders.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.