Corruption of the heap & F12 Problem

Question

I'm trying to draw a line using GLUT with C++ - the IDE is VS 2008 -but an error message occurred :

Windows has triggered a breakpoint in Graphics.exe.

This may be due to a corruption of the heap, which indicates a bug in Graphics.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Graphics.exe has focus.

The output window may have more diagnostic information

of course I don't have any breakpoint in my code this is my code :

#include <glut.h>


void init (void)
{
 glClearColor(1.0,1.0,1.0,0.0);
 glMatrixMode(GL_PROJECTION);
 gluOrtho2D(0.0,200.0,0.0,15.0);
}//end of the function init

void lineSegment(void)
{
 glClear(GL_COLOR_BUFFER_BIT);

 glColor3f(1.0,0.0,0.0);
 // D R A W  A     L I N E 
 glBegin(GL_LINES);

  glVertex2i(180,15);
  glVertex2i(10,145);

 glEnd();

 glFlush();
}//end of the function "lineSegment"
void main(int argc, char** argv)
{
 glutInit(&argc,argv);
 glutInitDisplayMode(GLUT_SINGLE|GLUT_RGB);
 glutInitWindowPosition(50,100);
 glutInitWindowSize(400,300);
 glutCreateWindow("N.S"); 
 init();
 glutDisplayFunc(lineSegment);
 glutMainLoop();

}//end of the "Main" function

Anyone know the problem?

Answer 1

I got this same error message when programming in visual studio in C, totally unrelated to the F12 key. For anyone else programming in C who found this post via Google - my error was caused by a dangling pointer I had in my code.

Check all of your "free" statements and make sure you don't have any pointers left that refer to the memory you are deallocating.

Answer 2

Just to add to what D.Shawley's written: The F12 key is quite handy, once you know about it.

It's worth stressing that the F12 key is only active while a debugger is attached and this key acts normally when there's no debugger. Still, it's safer to avoid mapping the F12 shortcut to anything useful in your app, for those times when somebody needs to debug.

Answer 3

A little googling produced some results. It looks like F12 is reserved by the OS when you are running in the debugger. Here is a good thread about the subject. There is a workaround available from MSFT in this connect article. This gist of it is that when a debugger is active, the OS responds to F12 by entering the debugger at exactly the line of code that is currently executing.

If you are not in a debugger, then this is probably a stack corruption problem. Your code snippet looks pretty simple, but I do not know GL well enough to know if you are missing a required call or breaking some other procedural rule.