| User | Post |
Dish
Posts: 536/596 |
Originally posted by HyperHacker
VB has awesome debugging, though. You don't need to do that.  Use breakpoints and debug.print; you can even type code in the Immediate window and press Enter to execute it. (Of course, in C's defense, this is only possible because VB is interpreted, but yeah.  )
VS lets you do an 'edit and continue' feature with C/C++ where, when the program is broken (like on a breakpoint), you can edit some of the code and then continue program execution without rebuilding. Although it will only work two or three times before you have to rebuild -- it's still enough to fix the minor quirk here and there.
I'm telling you -- there's no substitute for a good debugger. All these ideas with printf and beep and MessageBox and all the other crap everyone does are great ---- when you have no other options. But nothing beats having a real... actual.... good.... debugger.
One of the reasons I still use VS.. in fact. I can't tell you how much of a pain in the ass some of my bugs in my emu would have been to chase down without a debugger. And I don't even know how to use most of VS's debugging tools. |
beneficii
Posts: 428/567 |
OMG OMG OMG I just found out what was wrong with my program!
The problem was in a careless variable initialization in a class method that caused it to sometimes try to read from a NULL pointer as though it were an arrary. It's so embarrassing. 
I am getting tired for playing these search around games, but thankfully they're getting less and less.  |
Kyoufu Kawa
Posts: 2043/2481 |
But... but.... I like wading through the game's log! |
HyperLamer
Posts: 6510/8210 |
Originally posted by Kawa-oneechan
Umm... no.
It happened out of any loop. In the initialization code.
It needn't be in a loop, necessarily. That's just where you start. Basically anywhere you'd put a printf, put an assert instead, so you don't get a lot of useless output telling you everything is still alright. |
beneficii
Posts: 426/567 |
For me, I think that using break or goto to test your program would be easier then commenting out a bunch of your code. I actually did the goto statement (I know I know the goto statement is evil; I only am using it for testing) in a function and the problem that turned out was a flag that got set that caused another function later on to get messed up (I have a couple ideas to what it is). I thought the problem was a lot more complicated, but I'm starting to get a little confident again.
When I get home from work tonight, I'm going to set to it. |
Kyoufu Kawa
Posts: 2032/2481 |
Umm... no.
It happened out of any loop. In the initialization code. |
HyperLamer
Posts: 6490/8210 |
VB has awesome debugging, though. You don't need to do that. Use breakpoints and debug.print; you can even type code in the Immediate window and press Enter to execute it. (Of course, in C's defense, this is only possible because VB is interpreted, but yeah. )
Also, Kawa, that's exactly what assert() is for. Instead of having to constantly watch for a specific output, you could just put 'assert(YDimGame != 0)' in a commonly-executed loop or something. IIRC the program will stop, or at least warn you, once that condition becomes false, and then you just look at the rest of the debug output to see what happened. (Tip for VB users: debug.assert.  ) |
beneficii
Posts: 424/567 |
Originally posted by Kawa-oneechan
I myself required some nice debugging myself. YDimGame kept resetting to zero! So I peppered my code with printf("DEBUG: YDimGame is now %d\n", ydimgame); lines.
Eventually, I found that my game's config routines were loading the player's pant color into ydimgame 
So yeah, PrintF for the win.
In VB, I just click auto-comment and remove apostrophes until it breaks, basically.
Hmm, commenting it out until it breaks actually seems to be a good idea. Thanks Kawa! |
Kyoufu Kawa
Posts: 2025/2481 |
I myself required some nice debugging myself. YDimGame kept resetting to zero! So I peppered my code with printf("DEBUG: YDimGame is now %d\n", ydimgame); lines.
Eventually, I found that my game's config routines were loading the player's pant color into ydimgame
So yeah, PrintF for the win.
In VB, I just click auto-comment and remove apostrophes until it breaks, basically. |
beneficii
Posts: 423/567 |
Originally posted by sloat
With Visual Studio, I'm pretty sure you have to run the app through the IDE. I'm not 100% sure though and I'm not sure if that applies to Bloodshed. It could also be that your breakpoint is just never reached.
I was thinking that the breakpoint was not being reached also, so I put it in the first line of the WM_CREATE of my main window (which did load), but the program still did not break execution.
I'm not entirely sure how Bloodshed does it. I read through the help file. (I think the Help file has bad formatting, too). Here is text from it:
Launching your program into the debugger is easy. Just go to the Debug menu and click on Debug (shortcut : F8).
If you do not have debugging information set in your project, Dev-C++ will ask you if you want to rebuild your program with these information enabled. You can manually select that option in Compiler Option in the Linker section. After your project has been rebuild, you can launch Debug again.
The debugger has now loaded your program and runs it. but until that you can learn to control several aspects of the debugger :
- Setting Breakpoints in your codeID_BREAKPOINT
- Stepping in your codeID_STEPDEBUG
- Displaying variables value and classes/structures membersID_DISPLAYDEBUG
- BacktracingID_BACKTRACE
- Using the CPU WindowID_CPUWINDOW
The output Dev-C++ receives from GDB is displayed in the Debug Output sheet at the bottom of Dev-C++.
This output is probably only interesting if you are familiar with GDB. You can also send commands directly to it (if you do not know GDB, you can type the help command for to have a list) by using the edit box just above the output (see screenshot below).
I'm not entirely sure what debugger information is, but I did set a breakpoint in the code and click Debug. It asked me if I wanted to compile with information and I said yes. It compiled, I then simply ran it. The breakpoint was set on the first line of the code in the body of case WM_CREATE in the WndProc's switch(msg) statement. The windows loads fine, but the program does not break. Perhaps there is somebody familiar with Bloodshed here? |
sloat
Posts: 75/85 |
With Visual Studio, I'm pretty sure you have to run the app through the IDE. I'm not 100% sure though and I'm not sure if that applies to Bloodshed. It could also be that your breakpoint is just never reached. |
beneficii
Posts: 420/567 |
Originally posted by Disch
ahh yeah... I used to do that too before I got semi-familiar with VS's debugger.
Breakpoints, variables watches, and memory viewers beat Message boxes anyday ;D
Anyway, another alternative would be to output to a text file or something instead of doing a message box. I'd still recommend a debugger over that though.
OK, I looked at Bloodshed's debugger and read the help file for it. Nevertheless, I have some questions: How do I get my program to stop at a breakpoint? I set a breakpoint and then do the debug compile and run it, but it doesn't stop at that breakpoint. I know I'm missing something, but I can't find it in the help file (which gives no good example).
Thanks. |
HyperLamer
Posts: 6396/8210 |
Ah yes... How could I forget Beep()? That's how they debugged computers before command lines even existed. Hell, even now, your BIOS will use it if something goes horribly wrong. Plus, random beeps are fun. |
sloat
Posts: 74/85 |
Debuggers...breakpoints...watches...MessageBox...assert...logging...all pale in comparison to the awesome power of Beep! |
HyperLamer
Posts: 6371/8210 |
Keh. Debugging = printf(), scanf() and assert(). Seriously, it's pretty simple to make a simple debug console on the command line - put some button or something in that prompts for a simple command - and REALLY useful. |
Dish
Posts: 531/596 |
ahh yeah... I used to do that too before I got semi-familiar with VS's debugger.
Breakpoints, variables watches, and memory viewers beat Message boxes anyday ;D
Anyway, another alternative would be to output to a text file or something instead of doing a message box. I'd still recommend a debugger over that though. |
beneficii
Posts: 412/567 |
Originally posted by Disch
Crashes like this usually aren't that hard to track down -- just find the line that the program is crashing on (this can be done in MSVS very easily by hitting the "break" option when the program crashes). When you know where the thing is going wrong -- examine everything that could make it go wrong -- whether it be a bad pointer, an out-of-bounds write, or whatever.
So yeah -- you gotta isolate the crash in order to solve it. If the crash is predictable, consistent, and easily reproduced (you made it sound like it's all three), then you should have no trouble finding out where the problem is. Like I said just break execution at the stack -- if it puts you at some garbage code (like some disassembly or a standard lib file), move back on the call stack until you reach your code.
Well, my normal mode was just by putting message boxes and testing where the crash occurs. For some reason, the message box was stopping it crashing and that's what has me confused, but I'll see if Bloodshed has that break option. |
Dish
Posts: 530/596 |
Crashes like this usually aren't that hard to track down -- just find the line that the program is crashing on (this can be done in MSVS very easily by hitting the "break" option when the program crashes). When you know where the thing is going wrong -- examine everything that could make it go wrong -- whether it be a bad pointer, an out-of-bounds write, or whatever.
So yeah -- you gotta isolate the crash in order to solve it. If the crash is predictable, consistent, and easily reproduced (you made it sound like it's all three), then you should have no trouble finding out where the problem is. Like I said just break execution at the crash -- if it puts you at some garbage code (like some disassembly or a standard lib file), move back on the call stack until you reach your code. |
beneficii
Posts: 410/567 |
Originally posted by Lenophis
Well, I'm not really sure, but it could be an hWnd problem. That, or a pointer is giving a problem.
Could you paste the switch code?
I'd prefer not. It's under a case in the switch(LOWORD(wparam)) under the case WM_COMMAND. Essentially, if I put up a message box anywhere around the modeswitch function (or in it), then the program won't crash. But if I don't put up the message box, then the program will crash. Also, if I call modeswitch after that to load another world, it seems that'll make the program crash too. |
Lenophis
Posts: 656/830 |
Well, I'm not really sure, but it could be an hWnd problem. That, or a pointer is giving a problem.
Could you paste the switch code? |
| This is a long thread. Click here to view it. |
