Help debugging in VC++ 6
by Erik Madison · in Technical Issues · 07/23/2003 (4:28 pm) · 3 replies
I'm having a hella time getting the debugger to work, even though I've used it on other projects before with no troubles.
I set a variable someplace, and much later I need to use it. It's garbage by then, so I need to figure out when/where that happens.
I've compiled in debug build... I try to set a watch, it won't let me type the name, nor drag/drop it in place. Bah. I set a breakpoint nearby, compiler says '1 or more breakpoints are invalid and have been disabled'. Groan. Okay, I'll just step through 50 trillion lines until I hit the ones I need. Compiler wants to know where (file) CRT0.C is located. Huh? WTF is that? I click cancel and the debugger drops into assembly.
Sheesh. The only thing that works is an F5 run, but without breakpoints or watches thats pretty friggin useless.
Like I said, I've debugged other projects with no problems. I even re-read all my docs just to make sure I hadn't forgotten how.
Anyone have a clue whats wrong?
I set a variable someplace, and much later I need to use it. It's garbage by then, so I need to figure out when/where that happens.
I've compiled in debug build... I try to set a watch, it won't let me type the name, nor drag/drop it in place. Bah. I set a breakpoint nearby, compiler says '1 or more breakpoints are invalid and have been disabled'. Groan. Okay, I'll just step through 50 trillion lines until I hit the ones I need. Compiler wants to know where (file) CRT0.C is located. Huh? WTF is that? I click cancel and the debugger drops into assembly.
Sheesh. The only thing that works is an F5 run, but without breakpoints or watches thats pretty friggin useless.
Like I said, I've debugged other projects with no problems. I even re-read all my docs just to make sure I hadn't forgotten how.
Anyone have a clue whats wrong?
About the author
#2
It's probably looking for that file to show you the C startup code that gets executed prior to main(). It's not something you are likely to be interested in.
One common cause of "invalid breakpoints" is not setting the breakpoint on the last line of a multiline statement. If you write an if statement like this:
if (condition_a_is_true &&
condition_b_is_true ||
condition_c_is_true) { // BREAK POINT GOES HERE
}
you must set the breakpoint on the line with "condition_c_is_true", not on the line with the "if" keyword.
If the program you are working with is large, I wouldn't recommend using a watch. It will take forever. You are better off with the old fashioned divide and conquer method using a binary search.
Pick a point near where you think the variable is getting corrupted and set a break there. When the program stops at the breakpoint, check the variable. If it's already corrupted, pick an earlier point to set the breakpoint. Otherwise, pick a later point.
Also, remember that the debugger can not interrupt your program to stop at a breakpoint if you are running the game in fullscreen mode. You may need to modify your DirectX routines to allow the program to run in a window.
--milo
http://www.starshatter.com
07/24/2003 (5:09 pm)
CRT0.C is part of the C Run Time library source code. You should have had the opportunity to install the CRT source code when you installed the compiler. I don't have VC6 installed on this machine (I'm at work) but if you poke around in the install directories you will find it eventually if you installed it.It's probably looking for that file to show you the C startup code that gets executed prior to main(). It's not something you are likely to be interested in.
One common cause of "invalid breakpoints" is not setting the breakpoint on the last line of a multiline statement. If you write an if statement like this:
if (condition_a_is_true &&
condition_b_is_true ||
condition_c_is_true) { // BREAK POINT GOES HERE
}
you must set the breakpoint on the line with "condition_c_is_true", not on the line with the "if" keyword.
If the program you are working with is large, I wouldn't recommend using a watch. It will take forever. You are better off with the old fashioned divide and conquer method using a binary search.
Pick a point near where you think the variable is getting corrupted and set a break there. When the program stops at the breakpoint, check the variable. If it's already corrupted, pick an earlier point to set the breakpoint. Otherwise, pick a later point.
Also, remember that the debugger can not interrupt your program to stop at a breakpoint if you are running the game in fullscreen mode. You may need to modify your DirectX routines to allow the program to run in a window.
--milo
http://www.starshatter.com
Torque Owner Erik Madison