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?
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.
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.
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.
Related
I'm currently programming an SDL Network Game, everything is perfect ... But my game only runs at 30fps, so I ran a Very Sleepy analysis.
First strange effect, very sleepy increase the perfs of my Game to 60Fps ... ( Why ? )
And secondly, there is a lot of SDL_LogCritical calls ( you can get the report here : http://puu.sh/gauEi/9a852462e6.png ). And nothing is shown in the console.
( I also use SDLNet, with TCP protocol, there is no packet loose ).
Moreover, I overwritten the output for SDL Logs :
void log(void* userdata, int category, SDL_LogPriority priority, const char* message) {
std::cout << "Log : " << message << std::endl;
}
int main(int argc, char **argv) {
SDL_Init(SDL_INIT_EVERYTHING);
SDLNet_Init();
SDL_LogSetOutputFunction(log, NULL);
SDL_LogCritical(1, "TEST LOG");
}
And I can see the "TEST LOG" in the console. So the SDL_LogCritical which consumme 30% doesn't output everything .
I don't know what's wrong, but frequent calls to a logging function indicate that something is wrong and SDL tries to tell you about it. However, the lack of output might be caused by you explicitely or implicitely disable logging to the console. Your use of Network might indicate your not looking at the right console to see these warnings. It's all a bit hard to diagnose with the lack of information given.
Performance increase due to debugging is strange, but can often be explained by the fact that the debugger doesn't use exactly the same environment as you do when running normally.
OK, so you're not seeing output when something else calls SDL's log functionality. This points to the messages being logged somehow being below necessary priority. Compare SDL's source code to find out how that could be happening. Maybe you should, at this point, use a debugger to set breakpoints.
Every time I compile my simple SDL1.2 code it's compiled successfully
but when I try to run it via terminal (alt+t in Ubuntu):
./game
Segmentation fault (core dumped)
I get this error. Can you help please? This is the code:
#include<SDL/SDL.h>
int main(int argc,char args)
{
SDL_Init( SDL_INIT_EVERYTHING);
SDL_Surface* screen;
screen=SDL_SetVideoMode(640,480,32,SDL_HWSURFACE);
SDL_Flip(screen) ![problem running the program][1];
SDL_Delay(5000);
SDL_FreeSurface(screen);
SDL_Quit();
}
SDL_SetVideoMode returns NULL on error which you do not check for.
Since you're running this via a terminal, I suspect you may have forgotten to tell Xorg to allow running from it. In fact, if this is really the problem it'll prevent any program from running when started that way.
To fix the problem, enter this into the terminal (this only needs to be done once per session):
xhost +
You should get a message that it was successful. I cannot recall the exact message, but it is something like this:
Clients are now allowed to connect from any host.
What was happening (assuming that I was correct regarding xhost) was that the SDL_SetVideoMode() call was failing and returning NULL, because Xorg rejected the connection. Since you're not checking for that, SDL_Flip() ended dereferencing a NULL pointer --- hence the segfault.
SIDE-NOTE: There is an error in your code, however --- namely, you should not call SDL_FreeSurface(screen);; that particular surface is special, and is freed by SDL_Quit(); automatically. Source (see "Return Value" section): http://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlsetvideomode.html
Check if SDL_SetVideoMode() failed!
screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE);
if (screen == NULL) /* error */;
Run it under valgrind. Or GDB. Or some other debugger of your choice.
You should probably be successfully allocating memory for screen.
So if I write the following code:
MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
the program crashes with an access violation when it exits. When I write the code like this:
int a;
a = MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
it doesn't crash. Now I know why it crashes when it crashes thanks to another question I asked, also regarding argument-mismatching, but I don't know why it crashes.
So why does this cause an APPCRASH? I was always under the impression that calling a function that had a return-type, without actually giving one was safe, example:
int SomeFunction (void) {
std::cout << "Hello ya'll!\n";
return 42;
}
int main (void) {
int a;
// "Correct" ?
a = SomeFunction();
a = MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
// "Incorrect" ?
SomeFunction();
MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
}
When I run this kind of test "clean" (in a new file) I don't get any errors. It only seems to give an error with MessageBox/MessageBoxA when run in my program. Knowing the possible causes would help me pinpoint the error as the project code is too big to post (and I would need my friend's permission to post his code anyway).
Additional Info:Compiler = GCCPlatform = Windows
EDIT:
UpdateThanks everyone for your feedback so far. So I decided to run it through a debugger... Now Code::Blocks doesn't debug a project unless it is loaded from a project file (*.cbp) - AFAIK. So I created an actual project and copy-pasted our project's main file into the projects. Then I ran in debug mode and didn't get so much as a warning. I then compiled in build mode and it ran fine.Next, I decided to open a new file in Dev-C++ and run it through the debugging and later the final build process and again I got no errors for either build or debug. I cannot reproduce this error in Dev-C++, even with our main file (as in the one that causes the error in Code::Blocks).
ConclusionThe fault must lie in Code::Blocks. AFAIK, they both use GCC so I am pretty confused. The only thing I can think of is a version difference or perhaps my compiler settings or something equally obscure. Could optimizer settings or any other compiler settings somehow cause this kind of error?
The version with the return value does not crash because it had one int more on the stack. Your erroneous code reads over the bounds of the stack and then runs into an access violation. But if you have more on the stack you will not hit the guard page, because that is just enough extra stack. If the the erroneous code only reads it is sort of OK, but still broken.
We had one bit of WTF inducing code that was like so:
char dummy[52];
some_function();
There was thankfully a longish comment explaining that removing dummy, makes some_function crash. It was in a very old application so nobody dared touch it and the some_function was totally different module we had no control over. Oh yea and that application was running smoothly in the field for over 20 years in industrial installations, like refineries or nuclear power plants... ^_^
I am new to C++, and I am trying to program a replica of Pong using freeglut with Visual Studio 2010. My code was working fine until I made some revisions to it in order to make it more object oriented. When I ran it again, it worked a couple times, until I made some minor edit (to be honest, I can't remember what it was that I changed, since I only built my code the next morning), and I received this runtime error as soon as I ran the program:
Unhandled exception at 0x1000bbae in Pong.exe: 0xC0000005: Access violation writing location 0x000000a8.
I'm not particularly good at debugging, but I believe this is coming at the line glutDisplayFunc() in my main loop. I think this has something to do with null pointers, but I have no idea what. Could somebody help me find my problem?
Below is the applicable portion of my program (Main.cpp):
include "header.h"
using namespace std;
int main(int argc, char** argv) {
//Initialize GLUT
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
glutInitWindowSize(WIDTH, HEIGHT); //Set the window size
//Create the window
//modesetup(2);
//Set handler functions for drawing, keypresses, and window resizes
glutDisplayFunc(mainDraw);
glutKeyboardFunc(handleKeypress);
glutKeyboardUpFunc(handleKeyup);
glutSpecialFunc(handleSpecial);
glutSpecialUpFunc(handleSpecialUp);
glutReshapeFunc(handleResize);
glutTimerFunc(25, update, 0);
glutMainLoop(); //Start the main loop. glutMainLoop doesn't return.
return 0; //This line is never reached
}
Thanks in advance!
EDIT: I just made a new program that uses very standard functions for everything, but I still get this error. I'm beginning to think that there may be something wrong with my freeglut installation.
Use F5 to run the program with debugging in visual studio. When you get the error the debugger should place you right on the line with the illegal access. If it doesn't have source code for the location then check up the call stack.
Cheers & hth.
Run your program under valgrind. It will give you a lot more information about the problem, and might even point out memory errors other than the immediate cause of the crash.
You probably already solved the problem. But since I had the same problem and couldn t find an answer two it anywhere I will answer the question:
You simply forgot to write the
glutCreateWindow("Windowname");
function before the
glutDisplayFunc(mainDraw);
glutKeyboardFunc(handleKeypress);
glutKeyboardUpFunc(handleKeyup);
glutSpecialFunc(handleSpecial);
glutSpecialUpFunc(handleSpecialUp);
glutReshapeFunc(handleResize);
glutTimerFunc(25, update, 0);
part.
This leads to the exception you get.
I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}