OpenGL release build closes immediately

[idratex]

I have been learning OpenGL 2.1 for a bit and I'm currently satisfied with my rotating textured cube :P.

However it only works in the Debug build (I'm using VS Express 2010) and in the Release build it just opens a blank window which closes immediately. To be honest, I don't have a clue why this is happening, but I am aware that Release builds of applications can be home to dreaded "Release-only" bugs and that this may be one. I will post code if it helps but since there is quite a bit I'm not sure which parts would be relevant.

I am using freeGlut, GLEW and SOIL if this helps.

So, if anyone has an idea on why this is happening and how to solve it, this would be greatly appreciated! :D

[bbgst]

General tip, without seeing your code: use strategically placed cout's to find out exactly where your error is. Example:

int main(int argc, char ** argv)
{
    cout << "Well, at least it runs!" << endl;
    operation1();
    cout << "returned from operation1()" << endl;
    operation2();
    cout << "returned from operation2()" << endl;
    // ... 

Remember to use endl (or cout.flush() to avoid buffering problems).

[Disch]

couts are like a poor man's debugger.

It's much easier to use an actual debugger. Set a breakpoint at the start of the code and step through it. Not only can you find out what is executing and when, but you can also examine the contents of pretty much any variable.

Setting a breakpoint in Visual Studio I believe is F9 by default (it'll make a red circle on the current line). When you run (I think F5 by default), when the code gets to that point it'll freeze the program and jump back to visual studio and you can look at your program status. You can then Step Into (F11) or Step Over (F10) your code and trace program execution.

[BlackSheep]

I found that when using MSVS bools would be set to true if you left them uninitialized. This can cause funny release errors having to do with while loops which depend on a bool. (ie. Your game loop might seem perfect in debug because the allocated bool is always true on initialization. Then, when you compile a release build, your while loop might not run.) I think the other basic types also initialize to a set value in debug builds automatically, so you might want to check that out.

[bbgst]

That's one of the most stupid thing I've ever heard (read). Doesn't it even generate a warning?

[BlackSheep]

It cause me some grief a while back. I'm not sure, I didn't read warnings back then :P It probably gave you a warning about using a variable before initializing it.

[S6k9GNh0]

There are OpenGL debuggers which I use. They track various things concerning OpenGL (including error codes thrown) so you don't have to riddle your code with crappy output logs.

I use BuGLe: http://sourceforge.net/projects/bugle/
However, there are three or four more that are at least usable and do about the same thing. These tools are an absolute heaven send when learning OpenGL although, if you're using anything past OpenGL 3.2, you might run into incompatibility issues (although, most let you manually add them).

[idratex]

Ha! Thanks for the advice. Turns out I should have checked the compiler warnings LOL...

I had a bool-returning function that I checked and if it returned false, the program would exit. I had made the function return false on failure, but forgot to make it return true on success >_< HERP DE DERP

Using what BlackSheep said, since the bool return value would have been set to true automatically in the debug build, but not in the release build, this was the source of the problem.

After rectifying this, it works! Thanks again! :D

[bbgst]

That is why you should:
- always check (and correct) warnings.
- never rely on undefined behaviour (as it is, not surprisingly, undefined).

And by correcting the warning, I mean correcting the error, not disabling it.