Debugging in C++
How are you supposed to find bugs in C++?
I come from a mostly java background. 98% of my bugs are NullPointerExceptions and me forgetting to assign variables or bad programming. 1% is ArrayOutOfIndexExceptions from bad math or off by one errors. The rest is the hard to find stuff. What I find especially useful is the stack trace which tells me exactly where I screwed up.
In C++, when I use a null variable, the program just crashes. There is some error code . But that's it. I have no idea where the code crashed because there is no stack trace. In cases where my program throws an exception, all I get is brief explanation. Again, I have no idea where the crash occurred is. I'm tired of writing print statements to find where the crashed occurred. Does C++ or any IDEs offer anything that can assist me? I would prefer a solution that does not take 10s to load up every time I run the program.
I come from a mostly java background. 98% of my bugs are NullPointerExceptions and me forgetting to assign variables or bad programming. 1% is ArrayOutOfIndexExceptions from bad math or off by one errors. The rest is the hard to find stuff. What I find especially useful is the stack trace which tells me exactly where I screwed up.
In C++, when I use a null variable, the program just crashes. There is some error code . But that's it. I have no idea where the code crashed because there is no stack trace. In cases where my program throws an exception, all I get is brief explanation. Again, I have no idea where the crash occurred is. I'm tired of writing print statements to find where the crashed occurred. Does C++ or any IDEs offer anything that can assist me? I would prefer a solution that does not take 10s to load up every time I run the program.
You build it with debug symbols, and you run it under a debugger. The debugger catches the crash and shows you the line it's crashing on, and the stack, and the value of the variables. Then you reason about why it has crashed.
https://msdn.microsoft.com/en-us/library/sc65sadd.aspx
https://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html
http://wiki.codeblocks.org/index.php/Debugging_with_Code::Blocks
and so on.
Alternatively, you fiddle with your OS so that it saves crash dumps, and then you use a debugger to examine the crash dump.
On some operating systems, you don't need to run it under a debugger. The OS will catch it at the point of crash, and give you the option to debug at that point.
https://msdn.microsoft.com/en-us/library/sc65sadd.aspx
https://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html
http://wiki.codeblocks.org/index.php/Debugging_with_Code::Blocks
and so on.
Alternatively, you fiddle with your OS so that it saves crash dumps, and then you use a debugger to examine the crash dump.
On some operating systems, you don't need to run it under a debugger. The OS will catch it at the point of crash, and give you the option to debug at that point.
Last edited on
it's just the way the lang was designed. If you have an array of size 50 and then start trying to write to index 60, or output index 60, it could still "work" -- the phrase is famously called Undefined Behavior. See https://en.wikipedia.org/wiki/Undefined_behavior
Here are some articles about crash reporting. I haven't tried them so I can't if and how they work.
https://www.codeproject.com/search.aspx?q=crash+report&x=0&y=0&sbo=kw
https://www.codeproject.com/search.aspx?q=crash+report&x=0&y=0&sbo=kw
I use a mixture of techniques... adding print statements (be sure to flush them so they print immediately), debugger, watches, conditional breakpoints, commenting out blocks to isolate the line are my most common tools. You do want to use a powerful IDE with a good debugger; visual studio is very good. How long it takes to bring up the debugger depends on your system, the tool, and the program being debugged. Most tools these days take forever to open or do anything; even simple things like word processors have to connect to the mothership, verify who you are, steal your information, run through a virus checker, check your system's date and time against the bank, do a benchmark on your hard drive, update your drivers, verify your mouse, chat with someone in siberia, and draw some unnecessary graphics and logos before they can even think about letting you do any work. The current state of tools is depressing, but the 10 seconds to open is still a lot faster than trying to debug it without good tools, so you need to put up with the slowness if you want to save time overall.
Topic archived. No new replies allowed.