# KrtekOrchanoff

Member Since 19 Feb 2013
Offline Last Active Feb 20 2013 04:11 PM

### Unexpected behavior of glGetActiveUniformName

19 February 2013 - 10:43 AM

Hi,

glGetActiveUniformName is a function that can be used to query a GLSL uniform's name length according to the documentation. This can be done by setting uniformName to NULL (0) and suppling an GLsizei pointer as out variable to length. When doing this one would expect the length of the uniform's name to be returned in the length parameter, but this variable is unchanged after calling the function as described above. An error is given which is GL_INVALID_VALUE which, according to the documentation, can mean one of three things:

GL_INVALID_VALUE is generated if uniformIndex is greater than or equal to the value of GL_ACTIVE_UNIFORMS.

GL_INVALID_VALUE is generated if bufSize is negative.

GL_INVALID_VALUE is generated if program is not the name of a program object for which glLinkProgram has been issued.

In my case the uniformIndex is 0 and GL_ACTIVE_UNIFORMS reports 5. bufSize is set to 0 on purpose and therefore can't be negative. And calling glGetProgram with GL_LINK_STATUS on the program used returns GL_TRUE (1). This rules out all 3 known causes of this error. There have been no previous errors according to glGetError just before the call to glGetActiveUniformName and calling it with a valid bufSize and uniformName succeeds and writes to the buffer in uniformName as expected; correctly writing the uniform's name.

Apart from not reporting the length of the uniform's name and erring instead there are other troubling signs; if bufSize is set to a positive value greater than zero and uniformName is left NULL (0) the function writes to uniformName anyway potentially causing serious memory corruption. This behavior is not according to the specification either which states that should uniformName be NULL (0) then nothing shall be written to it.

Putting all the information above together I think I can safely conclude that there is no error in my code but instead there is an error somewhere outside of my own code which is why I am posting here. Is there anyone who can verify the behavior of this function when used as described above? I think this could well be a driver issue which means that only people running nVidia hardware would see the issue but it is too early to exclude any group of users.

P.s.: The above occurred on a machine running the latest drivers (updated specifically to verify the above statements) with an nVidia GeForce 660 GTX installed. The machine is a Dell XPS 8500 running 64-bit Windows 7 Professional SP1. The program was built using Visual Studio 2012 Professional, fully updated. This post was also posted to the nVidia Developer Forums.