GLSL crash

[Holmes]

I'm having some problems with GLSL (getting it working for the first time). Here is some code of mine:

int installShader(char *vertex, char *fragment) {

GLhandleARB vertex_handle, fragment_handle, program_handle; // handles to objects
GLint vertCompiled, fragCompiled; // status values
GLint linked;

const char *c_vert = (const char *)vertex;
const char *c_frag = (const char *)fragment;

vertex_handle = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
fragment_handle = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);
program_handle = glCreateProgramObjectARB();

// pass the shaders the souce
glShaderSourceARB(vertex_handle, 1, &c_vert, NULL);
glShaderSourceARB(fragment_handle, 1, &c_frag, NULL);


The program crashes at the line "vertex_handle = glCreateShaderObjectARB ..." I cannot, for the life of me, figure out why. The debugger gives me this:

#0 0x90004910 in szone_malloc
#1 0x90003520 in malloc
#2 0x97bfb294 in operator new
#3 0x97bfbb40 in operator new[]
#4 0x97b84374 in TPoolAllocator::allocate
#5 0x97b84bcc in initializeSymbolTable
#6 0x97b84b1c in generateBuiltInSymbolTable
#7 0x97b848f8 in ShInitialize
#8 0x005c9f34 in glCreateShaderObjectARB_Exec
#9 0x0000ee8c in installShader at ShaderManager.cpp:67
#10 0x0000c900 in Game_Init at game.cpp:58
#11 0x0000b5b4 in initGL at main.cpp:87


Additional, the run log tells me this:

Argonaut2(4843,0xa000ed98) malloc: *** error for object 0x1895a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
Argonaut2(4843,0xa000ed98) malloc: *** set a breakpoint in szone_error to debug"

I have made sure that it is not because of the most typical error I make, which is calling OpenGL functions before the context is set up. Other OpenGL calls are made before glCreateShaderObjectARB and they execute fine, and if I don't load the shader the game loads up and displays some animated ships flying around.



Any ideas?

[OneSadCookie]

Well, there's no reason for that call to crash, as long as the extension is supported and you have a current GL context. The stack trace suggests that the extension is supported (though you must check), so that leaves me believing that you don't have a current GL context, despite what you say ;)

assert(CGLGetCurrentContext() != NULL);

For some working code, take a look at shader.h and shader.c from http://onesadcookie.com/svn/repos/Kiloplane/. For usage, look at nvidia_pseudoinstancing_renderer.c -- but don't actually try to *use* that renderer on Mac OS X, you will crash, or worse :p

[Holmes]

Well, there's no reason for that call to crash, as long as the extension is supported and you have a current GL context. The stack trace suggests that the extension is supported (though you must check), so that leaves me believing that you don't have a current GL context, despite what you say ;)

assert(CGLGetCurrentContext() != NULL);

For some working code, take a look at shader.h and shader.c from http://onesadcookie.com/svn/repos/Kiloplane/. For usage, look at nvidia_pseudoinstancing_renderer.c -- but don't actually try to *use* that renderer on Mac OS X, you will crash, or worse :p

Gah, how am I supposed to download the Kiloplane project?

P.S. My program gets through the assert fine.
P.P.S. I checked the extensions that you check in Kiloplane, and I have them all.

[arekkusu]

What OS version and hardware are you using? And, is that the main thread crashing?

[OneSadCookie]

Gah, how am I supposed to download the Kiloplane project?

Grab subversion from http://www.codingmonkeys.de/mbo/ and install it. Make sure /usr/local/bin is in your path if it's not already. Then:

svn co http://onesadcookie.com/svn/repos/Kiloplane

P.S. My program gets through the assert fine.

Hmm... if you enable guard malloc, do you crash in a different place?

[Holmes]

What OS version and hardware are you using? And, is that the main thread crashing?

OS X v10.4.7
Powerbook G4 17" 1.33GHz, Radeon 9600 mobility

Yes, main thread. It looks like there are only two threads, and the second one just says:

#0 0x9000b268 in mach_msg_trap
#1 0x9000b1bc in mach_msg
#2 0x93647d60 in glcDebugListener
#3 0x9002bc28 in _pthread_body

[Holmes]

Grab subversion from http://www.codingmonkeys.de/mbo/ and install it. Make sure /usr/local/bin is in your path if it's not already. Then:

svn co http://onesadcookie.com/svn/repos/Kiloplane



Hmm... if you enable guard malloc, do you crash in a different place?

D'oh!

If I enable guard malloc it crashes here, which looks like the real culprit:
for(int i=0; !fp_in.eof(); characters[i++] = fp_in.get());


Turns out I just didn't have enough space in a string.
What does guard malloc do? I was fooled by the stack trace to think the problem originated from the GLSL function call. Why was the real culprit hidden from me?

[OneSadCookie]

In the debug menu. It's only active when in the debugger, too.

[TomorrowPlusX]

D'oh!

If I enable guard malloc it crashes here, which looks like the real culprit:
for(int i=0; !fp_in.eof(); characters[i++] = fp_in.get());



Eh.. I don't have any GL suggestions for you, but that line above makes my spidey sense tingle. Unless you know how much data will be coming in through fp_in ( say, be reading the file size in advance ) I'd recommend something like:


std::vector< char > characters;
for ( int i = 0; !fp_in.eof(); characters.push_back( fp_in.get() ));


That won't blow up so easily. And, since std::vector uses a contiguous store, you can easily get a pointer to the start with:


char *c = static_cast< char * >( &characters.front() );


Or something like the above.

std::vector is your friend!