Lecture 8
Last Time: Makefiles, Preprocessor This Time: Methodologies, gdb/valgrind, source control, modelling
Agile Method: client → specs → planning → programming → building → testing/debugging → source control → releasing → client (goes in a loop)
- Client is looped into the process
- Typically, work is done in 1-2 weeks, called “sprints”. Basically no one uses waterfall method.
Next: Testing / Debugging
Debugging in C++: Valgrind and gdb
Valgrind: Primary use is a memory checking tool.
- Provides a virtual CPU that it executes your program on - checks for memory access, etc.
Typically programs executed through valgrind are 3-4x slower than usual (don’t use it for performance monitoring).
It is important when using valgrind or gdb to compile with the -g flag.
Using --leak-check=full allows us to see where leaked memory was allocated.
Valgrind can only inform on memory leaks for one particular invocation of the program. Highlights importance of designing valgrind test cases that hit each part of the program.
Can also detect invalid reads: report the line of your source code where invalid read happened.
Invalid write - we get 3 pieces of information:
- Where the invalid write occurred
- Where the memory was freed
- Where the memory was initially allocated
Can also detect delete/delete[].
GDB gdb = GNU debugger: Useful for inspecting variables seeing control flow of program.
gdb ./myProgram
run - runs the program
runa arg1 arg2 arg3
run < test8.in
List of commands:
gdb ./myProgram
run - runs the program
run arg1 arg2 arg3
run < test1.in
break file : line-number
break fn-name - sets a breakpoint, allows us to stop program at this point
next - runs one line of the program
layout src - nicer display for source code
print variable - allows you to see value of that variable at that line
refresh - fix the layout src display
step - runs one instruction of the program
list - show surrounding lines of the program
backtrace - lists the sequence of function calls that got you to your current location
up/down - change the function in the call stack we are observingso as to inspect other variables.
set var - set variable to something else at run-time
continue - runs the program to the next breakpoint
display var - prints the value of that variable after each next step
undisplay 1 - stops displaying first var set with display
watch var - breaks the program whenever var is changed
delete breakPoint Number - remove breakpoint from use (watch and break)