Skip to main content
gamedev.net
🔒 Locked

Debugger?

Started by Boops 9 replies 250+ views
Original Post
Boops
Boops
Long ago I programmed in QBasic. In QBasic you can press CTRL-Break at any time to pause your program and see the line where your program currently is marked. And if an error happened (division by zero, out of memory,...) he gave you a window telling what was wrong, showing you the problem line in the code. Pretty handy for debugging stuff! When I moved to c++ (Dev-C++ 4.0) I missed that functionality, now all that happened when something went wrong was that the exe closed and I had to guess where in the code it went wrong. So now finally I decided that I wanted a debugger in DevC++4, and installed one called "Insight 5". But what's the point of this? You can indeed see the code of your program in there... but whenever the program is running, you can't do anything in the debugger! All buttons become grey until I close my program again. It can't do any of those things QBasic could. What can one actually do with it, other than seeing the same source code you cee in the C++ editor, and it's assembly version? EDIT: for example, my program gets in an infinite loop somewhere, with QBasic I'd have been able to see what loop by pressing CTRL-Break, but with this Insight debugger I can't do anything, all menus and buttons are grey as long as my program is open, and it doesn't show where in the code the program is busy... [edited by - boops on October 21, 2003 11:26:19 AM]
Zul
Zul
Why don''t you use breakpoints, text messages, or print statements? You can put breakpoints in critical functions to make sure they run, and also throw in watch variables to see the values of important variables (I''ve never used DevC++, only Visual C++, I''m just assuming that they''d have these kinds of options in their debugger). Use print statements within functions to make sure algorithms are working correctly, and functions are returning proper values. It can also be helpful to create a log file and dump these statements into it so that you can go back later if the program crashes. ctrl-break (pause) works in any IDE I''ve used. If it doesn''t flash to the exact line, at least you won''t have to restart your computer if you accidentally write an infinite loop.
oh hai
Zul
Zul
Ah, in that case, use breakpoints on your loops, and check your end conditions. If you have nested loops, the inner loop should be checked first. If you have function calls within loops, make sure that the functions are executing properly and returning correct values.
oh hai
Boops
Boops
I found some way to let the debugger go through the assembly code and showing marked lines (I don't see my program itself running anywhere tho), but after about 5 steps it sais "Unable to read instruction at BlahBlahBlah" and there it ends :/

EDIT: Oh wait, there appeared my SDL window, after many steps! This might get interesting...

[edited by - boops on October 21, 2003 11:36:55 AM]
Zul
Zul
quote:
Original post by Boops
I found some way to let the debugger go through the assembly code and showing marked lines (I don''t see my program itself running anywhere tho), but after about 5 steps it sais "Unable to read instruction at BlahBlahBlah" and there it ends :/


Sounds like your loops is running too long (end condition is too high, eg, i<100 when it should be i<50) and accessing an invalid address. Either that or you''re accessing an array that you''ve initialized too small.
oh hai
Boops
Boops
It got past the "unable to read stuff" after holding down the "S" button for a long time, and after lots of steps my SDL window popped up, so it might get interesting...
Boops
Boops
quote:
Original post by Boops
It got past the "unable to read stuff" after holding down the "S" button for a long time, and after lots of steps my SDL window popped up, so it might get interesting...



EDIT: Should there normally in a debugger be a way to go 10 commands at once? Or maybe 1000 or so? Pressing S all the time is getting annoying and there are tons of steps to go before the SDL program is even started up properly.
Zul
Zul
Well, sort of. Visual C++ has the option to Step-in/step-out/step-over any function or breakpoint. So if you stepped over a long function, the application would execute however many lines in that function (including loops) without you needing to hit any keys. The only problem this creates is that if your code error is in this block, you may not be able to figure out where it is breaking without stepping in to the function and going line by line. It can give you a general idea of where things are going wrong though.
oh hai
Peon
Peon
I usually right click -> run to cursor over blocks I think work. If the problem turns up to me in the block I skipped, I go back and step through the offending code til I find the problem.
Peon
Raduprv
Raduprv
Insight rules, but it has a few problems:

1. No hardware memory breakpoints. (this really sucks)
2. If you have some BIG arrays of structures, with lots of data in them, it crashes when you try to see the data.
3. Sometimes it crashes Win98.


Member of the Un-Ban nes8bit Association (UNA) (to join put this in your sig)
Height Map Editor | Eternal Lands | Fast User Directory
Zul
Zul
Boops, here's an online book describing the GDB (debugger in Dev-C++). Clicky

General resource page for Dev-C++, here

See if that helps ya out.

[edited by - Zul on October 21, 2003 2:07:28 PM]
oh hai

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.