View Full Version : Can't compile shader anymore

07-03-2011, 05:20 PM
Hi, I've recently started to get the Visual Studio message

Unhandled exception at 0x697a38f5 in qsim.exe: 0xC0000005: Access violation reading location 0xbe4d83cd.

when calling glCompileShader and having my program crash before reaching the next line and without receiving an exception. It succeeds to compile the shader if it's written on one line, but as soon as I add a new line to the shader file that I'm loading the shader from the compile fails. I've managed to compile (my many lines long shaders) without problems until now; I have no idea what change I made that made it behave like this, but now it just refuses to compile the shaders if they contain new lines. Is it possible that I have managed to screw the newlines up, and that I'm now using a different newline standard in my shader files than before?

07-03-2011, 08:20 PM
There isn't enough information here to determine why the compile fails. You should paste the code that's causing the problem. For example, are you reading the shader from a file and returning it as a C string? Or are you just passing it as one long string? Perhaps if you provided more details people would be able to help you.

07-03-2011, 11:44 PM
I'm reading both the vertex shader and the fragment shaders from files.

Here's the function I use for creating the shaders:

GLuint createShaderFromFile(GLenum shaderType, char* fileName)
printf("Loading shader file %s\n", fileName);

// Create shader object
GLuint shader = glCreateShader(shaderType);
if (!shader || glGetError() != GL_NO_ERROR) {
fprintf(stderr, "Error: Unable to create shader object\n");
return 0;

// Load source file from disk
FILE* f = fopen(fileName, "rt");
if (!f) {
fprintf(stderr, "Error: Unable to open file %s\n", fileName);
return 0;

fseek(f, 0, SEEK_END);
int length = ftell(f);
fseek(f, 0, SEEK_SET);
char* buffer = new char[length + 1];
fread(buffer, 1, length, f);
buffer[length] = '\0';
const GLchar* strings[] = { buffer };

// Feed source code into shader object
glShaderSource(shader, 1, strings, NULL);

delete[] buffer;

// Compile shader
printf("Compiling shader...\n");

// If compilation produced any messages, print them
GLchar log[16384];
GLsizei logLength;
glGetShaderInfoLog(shader, sizeof(log) - 1, &logLength, log);
if (logLength) {
printf("%s", log);

// Check if compilation was successful
GLint compileStatus;
glGetShaderiv(shader, GL_COMPILE_STATUS, &compileStatus);
if (compileStatus != GL_TRUE) {
fprintf(stderr, "Error: Shader compilation failed!\n");
return 0;
else {

return shader;

This is originally a function written by someone else in C, that I have just pimped up a bit by changing malloc to new[] and free to delete[] since I'm programming in C++.

I don't know how much information I need to provide for it to be possible to find the bug, but for example the shader file

void main() { gl_Position = gl_Vertex; }

(no newline) compiles while the shader file

void main() { gl_Position = gl_Vertex; }

(one newline) crashes upon compilation.

07-04-2011, 12:18 AM
Could u clear the char* buffer to 0 using this line

after u create the char* buffer and tell us if u still get this error.

07-04-2011, 12:43 AM
No I don't! :) At least both shaders I provided here works! I will tell you if I get this error anymore, but hopefully it's gone for good now. But how can this make any difference; fread will write all that memory over anyway, right (regardless of its previous content)? Thank you very much anyway!

07-04-2011, 02:49 AM
The heap memory given to you will be filled with garbage so u must clear it after u have obtained the pointer. This will make sure that there aren't any garbage values when u load in your shader.

07-07-2011, 08:22 AM
Yes, but what difference does it make if it's filled with random ones and zeroes or just zeroes? I mean fread will just write it over anyway without looking, won't it?

07-07-2011, 04:49 PM
Yeah it should but it does not. I ran the debugger on the code and I saw some of the last garbage characters not being removed. It is always safe to clear the buffers before using.

07-07-2011, 04:56 PM
Okay, thanks alot anyway, I was about to get crazy over this error :P Good thing to know in the future though, that not clearing buffers can lead to problems.