[Mono-bugs] [Bug 678374] New: GetShaderInfoLog does not return any information + specification violates string immutability

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=678374

https://bugzilla.novell.com/show_bug.cgi?id=678374#c0


           Summary: GetShaderInfoLog does not return any information +
                    specification violates string immutability
    Classification: Mono
           Product: MonoTouch
           Version: SVN
          Platform: iPhone
        OS/Version: Apple iOS 4.2
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Class Libraries
        AssignedTo: gnorton at novell.com
        ReportedBy: evan.olds at email.wsu.edu
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US)
AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.127 Safari/534.16

When executing GL.GetShaderInfoLog to retrieve information about a failed
shader compilation, the output string is never altered, even when the output
length indicates that there is info-log data available.

Also, all overloads contain a string as the last parameter, whereas all
overloads specified in the 'regular' OpenTK documentation
(http://www.opentk.com/files/doc/class_open_t_k_1_1_graphics_1_1_e_s20_1_1_g_l.html)
use a string builder. Any string passed to any method in C# should be
immutable, thus it seems the specification is incorrect.

Before calling GetShaderInfoLog, the info log length is queried:

int* oneInt = stackalloc int[1];
oneInt[0] = -1;
GL.GetShader(shaderId, All.InfoLogLength, oneInt);

This makes oneInt[0] = 205 (in my specific case) and this seems to imply that
there is log data available from the previous shader compilation failure.

Reproducible: Always

Steps to Reproduce:
1. Create a new pixel shader:
int psId = GL.CreateShader(All.FragmentShader);

2. Try to compile the following fragment shader (GL.ShaderSource,
GL.CompileShader, etc.):
@"varying vec2 texCoord;
varying vec4 vertexColor;
uniform sampler2D texture;
void main()
{
    // Sample from the texture
    gl_FragColor = texture2D(texture, texCoord) * vertexColor;
}"

3. Try to get the shader info log after compilation of the shader fails
(querying compile status gives a value of 0):
int* oneInt = stackalloc int[1];
oneInt[0] = -1;
GL.GetShader(shaderId, All.InfoLogLength, oneInt);
if (oneInt[0] <= 0)
{
    return "(unknown shader compilation error)";
}
string info = new string('\0', oneInt[0]);
GL.GetShaderInfoLog(shaderId, info.Length, oneInt, info);
Actual Results:  
The 'info' string is never modified. It would be nice if the following method
(available on the dektop implementation of OpenTK) was implemented in MonoTouch
to reduce ambiguity:

static string     GetShaderInfoLog (Int32 shader)

Whether the above is implemented or not, it seems as though any method that
fills string data should either have a ref string, out string, or StringBuilder
parameter. No overload of GL.GetShaderInfoLog has these.

Expected Results:  
Output string ("info" in my code example) should contain details about why the
fragment shader did not compile. As one last note, the shader I listed in the
repro steps compiles and runs fine on desktop OpenTK apps, but I am unsure as
to what is wrong with it in the Open GL ES 2.0 context. Is such a shader
expected to not compile?

- Tested with debugging using iOS simulator Version 4.2 (235).
- OpenGL ES 2.0
- Previous vertex shader compilation succeeds, using similar compilation code.
- I'm classifying the severity as major, as it appears the info log
functionality is completely broken. Additional posts have been made in forums
by others, about the same issue
(http://forums.monotouch.net/yaf_postst1424.aspx). It appears as though their
issue was never resolved.
- My suggestion is a specification change and/or addition of the following
function:
static string     GetShaderInfoLog (Int32 shader)

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.