Bug 36761 - glGetAttachedObjects ignores maxcount
Summary: glGetAttachedObjects ignores maxcount
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2011-05-02 01:10 UTC by Lauri Kasanen
Modified: 2011-05-02 09:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Lauri Kasanen 2011-05-02 01:10:04 UTC
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.
Comment 1 Brian Paul 2011-05-02 06:58:44 UTC
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.
Comment 2 Lauri Kasanen 2011-05-02 07:44:26 UTC
Yes, gdb points the segfault to this line in Irrlicht source:
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.
Comment 3 Brian Paul 2011-05-02 07:48:27 UTC
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.
Comment 4 Lauri Kasanen 2011-05-02 08:10:52 UTC
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.
Comment 5 Brian Paul 2011-05-02 08:45:49 UTC
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?
Comment 6 Lauri Kasanen 2011-05-02 09:34:57 UTC
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.