glLinkProgram crashes on Mac/M1

[lordbwah]

Hi, I’m working on porting my game (which works fine on Windows) to Mac. Specifically trying to test on the M1. I’m on macOS 13.5, fully updated on software and drivers.

I’m currently crashing at glLinkProgram for a specific GLSL shader, so cannot continue the program to call glGetShaderInfoLog. Compiling the vertex and fragment shader both succeeded with no errors (GL_COMPILE_STATUS == GL_TRUE).

It is a big shader (~1000 lines).

I use GLFW as well, I have the following set:

GLFW_CONTEXT_VERSION_MAJOR: 3
GLFW_CONTEXT_VERSION_MINOR: 3
GLFW_OPENGL_PROFILE: GLFW_OPENGL_CORE_PROFILE
GLFW_OPENGL_FORWARD_COMPAT: GLFW_TRUE
GLFW_OPENGL_DEBUG_CONTEXT: GLFW_TRUE

The actual shader + opengl version used by mac end up being 4.1.
The shader is #version 330 core (tested other variants too, 330, 410, 410 core)

Also, debug utilities like GL_KHR_debug and GL_ARB_debug_output are not available.

My main question is, how do I go about getting any kind of error message for this so I can start figuring out the issue? I’m hoping not to have to remove bits of code one by one and guess the issue.

[SimonMaracine]

Sadly, I think that your best bet is to try removing some shader code and see if the linking succeeds. I see from the image that you have the call stack of the crash and that it’s aborting in the function glpPrimitiveTypeGetScalarType. That might say something, but I don’t really know what.

Shader compilation or linking can fail for many, many reasons and usually they should set an error and exit gracefully. But it might be that you have a mistake in your shader code, which might strangely cause glLinkProgram to crash.

I saw OpenGL functions that simply segfault instead of failing gracefully, because those user mistakes are not covered in the specification. For example, glLinkProgram can fail gracefully in only three ways (if you look at the Errors section), but there might some other ways to misuse the OpenGL implementation, which can cause a crash.

My guess is that you do something wrong in the shader code, for which the GLSL compiler doesn’t handle correctly. That is called undefined behavior, because the OpenGL specification doesn’t tell what should happen when the user makes that mistake.

To understand better what I mean, almost a year ago I suddenly had a graphical bug in my OpenGL application, i.e. some models were not rendered correctly. And only after a few days I discovered that the bug was caused by the GLSL code and it was related to incorrectly using opaque objects (samplers). All shaders were compiling and linking just fine, but they were not actually working properly. In my case, I was doing something completely wrong, but the compiler was not returning with an error, because it wasn’t handling that particular mistake and instead it was just doing its best to generate the program code (wrongly).

Also, note that shaders have limitations, like a maximum amount of uniforms, or uniform blocks and many other. You said that you have a big shader. See if somehow you exceed some limit. And make sure that you don’t use some OpenGL features that are not available in OpenGL version 4.1. If you invoke undefined behavior anywhere in your program, expect anything to happen next, even unrelated things to the original bug.

Or it might be a bug in the implementation, but that’s very, very unlikely.

Hope it helps at least a bit.