C/Debugging. Note: You are looking at a static copy of the former Pine. Wiki site, used for class notes by James Aspnes from 2. Many mathematical formulas are broken, and there are likely to be other bugs as well. These will most likely not be fixed. Debugging in general. Basic method of all debugging: Know what your program is supposed to do. Detect when it doesn't. A tempting mistake is to skip step 1, and just try randomly tweaking things until the program works. Assertions. Every non- trivial C program should include < assert. Kernighan. Ritchie Appendix B6). Let's look at a contrived example. If we were clever, we might notice that the test in the for loop is using the mysterious - = operator instead of the < = operator that we probably want. So we'll have to see what we can get the computer to tell us. This means that any changes you see in the variables are the result of the previous displayed line. My favorite gdb commandshelp. Get a description of gdb's commands. Also used to restart your program from the beginning if it is already running. Debugging strategies. In general, the idea behind debugging is that a bad program starts out sane, but after executing for a while it goes bananas. Valgrind. The valgrind program can be used to detect some (but not all) common errors in C programs that use pointers and dynamic storage allocation. You can suppress all of the output except errors using the - q option, like this: valgrind - q ./my- program arg. You can also turn on more tests, e. Compilation flags. You can run valgrind on any program (try valgrind ls); it does not require special compilation. Automated testing. Unless otherwise specified, automated testing of your program will be done using the script in /c/cs. Examples of some common valgrind errors. Here are some examples of valgrind output. Uninitialized values. Consider this unfortunate program, which attempts to compare two strings, one of which we forgot to ensure was null- terminated: 1#include < stdio. Bytes definitely lost. Here is a program that calls malloc but not free: 1#include < stdio. Invalid write or read operations. These are usually operations that you do off the end of a block from malloc or on a block that has already been freed. An example of the first case: 1#include < stdio. How do we know which case is which? Not recommended: debugging output. A tempting but usually bad approach to debugging is to put lots of printf statements in your code to show what is going on. If you really need to use printf or something like it for debugging output, here are a few rules of thumb to follow to mitigate the worst effects: Use fprintf(stderr, ..) instead of printf(..); this allows you to redirect your program's regular output somewhere that keeps it separate from the debugging output (but beware of misleading interleaving of the two streams—buffering may mean that output to stdout and stderr appears to arrive out of order). If you must output to stdout, put fflush(stdout) after any output operation you suspect is getting lost in the buffer. Keep all arguments passed to printf as simple as possible and beware of faults in your debugging code itself. Category. Programming. Debugging C and C++ programs with gdb (and ddd) About gdb and ddd Getting Started with gdb Common Comands gdb info commands for getting application and debugger state. Attaching To an Already Running Process; Debugging A Crashed Program. Lets compile the 'debug
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2017
Categories |