weird gl.CompileShader() gl.GetShaderInfoLog issue on OS X 10.6 (not on 10.7/10.8/linux)

[notnot]

I am experiencing a weird problem where my code works fine on 3 of my test machines (OS X 10.7, 10.8 and linux) but not on a machine with OS X 10.6. The problematic machine can't compile any GLSL shader, it seems to always return gl.FALSE when asking for gl.COMPILE_STATUS. What is especially odd is that the info log is always empty, even if i introduce obvious errors in the source. Normally there will be useful messages in the info log when a compilation fails. The problematic machine is able to compile and link and run the very same shader just fine from my (original) C++ application. If I 'mess up' the shader source there, I do get sensible info log data back, so in principle, that machine can do what i want it to do...
The only other external package that my application depends on is glfw3.

What could be going on here? Could it be a glow/gl issue?

What is bothering me most is that the C++ code is doing the very same thing as the Go equivalent, and that the very same code works on 3/4 of my test machines...

This is the function I use to compile a shader:

func GLSL_Compile(name string) (uint32, error) {
    fmt.Fprintf(os.Stderr, "GLSL_Compile(%s)\n", name)

    // check source file type by extension
    var shaderType uint32
    ext := path.Ext(name)
    switch ext {
    case ".vshader":
        shaderType = gl.VERTEX_SHADER
    case ".fshader":
        shaderType = gl.FRAGMENT_SHADER
    default:
        return 0, fmt.Errorf("not a GLSL shader source file: '%s'", ext)
    }
    // open source file
    file, err := os.Open(name)
    if err != nil {
        return 0, fmt.Errorf("os.Open(): %s", err)
    }
    defer file.Close()
    // read data
    source, err := ioutil.ReadAll(file)
    if err != nil {
        return 0, fmt.Errorf("ioutil.ReadAll(): %s", err)
    }
    source = append(source, 0) // zero terminate string
    int8s := bytesToInt8s(source)
    // compile
    shader := gl.CreateShader(shaderType)
    sourcePtr := &int8s[0]
    length := int32(len(source))
    gl.ShaderSource(shader, 1, &sourcePtr, &length)
    gl.CompileShader(shader)
    info := GLSL_ShaderLog(shader)
    // check compile status
    var status int32
    gl.GetShaderiv(shader, gl.COMPILE_STATUS, &status)
    if status == gl.FALSE {
        gl.DeleteShader(shader)
        return 0,
            fmt.Errorf("Compile status: failed...\nInfo Log:\n%s\n", info)
    } else if len(info) > 1 {
        fmt.Fprintf(os.Stderr, "Compile Info Log:\n%s\n", info)
    }
    return shader, nil
}

Who can shed a light on this?

[notnot]

I forgot to mention that i am using package "github.com/errcw/glow/gl/2.1/gl"

[emidoots]

Can that same system run the GL 3.1 Cube Example ?

Are you properly utilizing runtime.LockOSThread ?

Why are you zero-terminating the string yourself and using bytesToInt8s instead of making use of e.g. gl.Str?

How is GLSL_ShaderLog impelemented?

If you can share a complete, minimalistic, example of the problem it would help us to debug it.

Aside from my above comments, I don't see anything obviously wrong with the above code.

[notnot]

slimsag:
That machine, i.e. OS X 10.6 supports only OpenGL 2.1.

Yes I have runtime.LockOSThread() in init().

I do my own slice conversion to avoid a copy. I don't think this is causing a problem because i have printed the contents of the converted source, and it is what it should be: a valid GLSL shader.

See here my GSL_ShaderLog function:

func GLSL_ShaderLog(shader uint32) string {
var logLen int32
gl.GetShaderiv(shader, gl.INFO_LOG_LENGTH, &logLen)
if logLen == 0 {
return ""
}
log := make([]byte, logLen)
gl.GetShaderInfoLog(shader, logLen, nil, (*int8)(gl.Ptr(log)))
return string(log)
}

Ok, my current test program is still fairly minimalistic, just setting up GLFW and OpenGL, building the shader and doing a simplistic rendering. It's currently only two files but i can easily turn it into one file. Where and how would you like to receive it? I can post it here if that is convenient. Thanks for looking into this, i am puzzled and slightly depressed by this unusual failure. All my other Go programming has always been so supersmooth till now!

[notnot]

Note that i have spent some time testing with pre-2.1 versions of shader functionality as well, ARB extensions based, to rule out the possibility that that machine somehow doesn't support the 'built-in' GLSL funtionality. Sadly the same here: it works in my C++ code, but not in my equivalent Go code :(

[dmitshur]

Which version of Go are you running?

[notnot]

1.3

On 28 November 2014 at 02:01, Dmitri Shuralyov [email protected]
wrote:

Which version of Go are you running?

—
Reply to this email directly or view it on GitHub
#49 (comment).

[dmitshur]

Do you mean 1.3.0? It may be a long shot, but can you try 1.3.3, which is the latest stable Go version, or perhaps even 1.4rc1?

[notnot]

Yes, i am using the plain 1.3 release here. I am using errcw/glow though, not go-gl/glow with the latest updates. I might try that tomorrow.

[emidoots]

That machine, i.e. OS X 10.6 supports only OpenGL 2.1.

I see. I apologize as I'm not 100% familiar with OS X yet.

I do my own slice conversion to avoid a copy.

FWIW gl.Str doesn't make a copy of the string, it just returns a pointer to it.

It's currently only two files but i can easily turn it into one file. Where and how would you like to receive it?

Even multiple files, if you could put it anywhere it would be useful to get a complete picture of the program (instead of just a segment of it).

A zip file uploaded to e.g. Google Drive, or even putting it into one of your own Git repo's would work great.

Another idea: Does gl.GetError say anything?

[notnot]

slimsag:
I reworked the code a bit, simplified it some more to get a nice bug reproducer. I put shader21.zip on my google drive:

https://drive.google.com/file/d/0BxruJsiZGIgaenhvRlh1VTBWQ0k/view?usp=sharing

All the people here, feel free to have a look at it. I am at a loss, can't understand why this code works on the majority of my machines and not on the one running OS X 10.6.8.

gl.GetError remains silent...

[notnot]

On that problematic machine i had a dual install of glfw2 and glfw3. To make sure the issue isn't caused by that i removed all glfw libraries from the system and reinstalled glfw3 from scratch (both the C library and the Go package). Sadly this didn't solve the shader compile problem...

[errcw]

A couple thoughts:

• OS X is reasonably particular when it comes to OpenGL context setup. You might consider adding explicitly hints (glfw.WindowHint) to set the OpenGL context version to 2.1.
• Does GLSL 1.1 support explicit version pragmas in the source files? You might also consider adding a #version marker. A related thought is to ensure your program is valid GLSL 1.1 (I'm forever losing track what features and syntax were enabled at what versions).

[notnot]

See here the relevant output on the problematic machine. The OpenGL version
is 2.1, which is the default on OS X, when you don't take special measures.
Note that this machine has no troubles compiling and linking the exact same
shaders in an earlier C++ version of the program i am developing...

GL version : 2.1 NVIDIA-1.6.40
GL vendor : NVIDIA Corporation
GL renderer : NVIDIA GeForce GT 330M OpenGL Engine
Checking required OpenGL Shader Language extensions:
has GL_ARB_shading_language_100
has GL_ARB_shader_objects
has GL_ARB_vertex_shader
has GL_ARB_fragment_shader
has GL_ARB_vertex_program
GLSL implementation specific limits :
16 - max vertex attributes
4096 - max vertex uniform components
4096 - max fragment uniform components
60 - max varying floats
16 - max vertex texture image units
16 - max combined texture image units
16 - max texture image units
8 - max texture coords
GLSL_Compile(data/def_c.vshader)
Init(): initGL(): GLSL_Compile(): Compile status: failed...
Info Log:

---------------- ^ ! the info log is always empty, unlike on other machines
where a shader fails to compile, the log contains warning and/or error
messages.

The shader that fails is extremely trivial:

void main()
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color;
}

No matter what nonsense i add to this shader, the info log never has a
message. ?! If i compile the 'nonsense' shader with the C++ variant, i do
see proper warning/error messages. I am stumped...

On 28 November 2014 at 19:11, Eric Woroshow [email protected]
wrote:

A couple thoughts:

• OS X is reasonably particular when it comes to OpenGL context setup.
  You might consider adding explicitly hints (glfw.WindowHint) to set
  the OpenGL context version to 2.1.
• Does GLSL 1.1 support explicit version pragmas in the source files?
  You might also consider adding a #version marker. A related thought is
  to ensure your program is valid GLSL 1.1 (I'm forever losing track what
  features and syntax were enabled at what versions).

—
Reply to this email directly or view it on GitHub
#49 (comment).

[notnot]

Pfew, i found and fixed a bug in my code. My issue didn't have anything to do with glow/gl or glfw3 or OS X in particular. The length i gave in gl.CreateShader() was 1 too large (it included the zero terminator). Apparently most OpenGL drivers are robust enough to handle such an error, but not all...

[dmitshur]

Glad to hear you got to the bottom of it, and it turned out not to be a bug in glfw3 or glow (if it had been, we would've fixed it).