Going deeper into debugging
Learning is not memorizing. Learning is grokking the “what it does” and “why to do it.” So now its time to dig deeper into understand what goes on in debugging, instead of just being a user of pdb. Here’s a list of what I think is going to happen in my learning process:
- Learning the terminology
- Learning the technology
- Learning the implementation
- Learning the class
- Learning the class methods
- Learning the instance methods
- Learning the source code of OPT
- Learning the flow of the program of OPT
- Learning how the Ruby world might do it
The process
The process of debugging:
- Issue recognition – identifying exactly what it is about the target being worked on that is coming across as incorrect
- Intelligence gathering – examining the target to understand the way that it works and the way the symptom is being produced
- Diagnosis – identifying the root cause of the symptom, the bug itself
- Prescription – planning out how the bug should be fixed
- Response – fixing the bug
- Verification – checking that the bug is now fixed and that the fix has not caused other bugs to be created
The terminology
Famous story – A navy admiral named Grace Hopper was having problems with her mainframe computer. She opened up the computer and found a moth in it that was preventing it from working properly. After pulling out the moth and making the computer function normally again she claimed the computer had been “debugged”.
Frame, Debug, Stack Trace, Trace, Backtrace, Exception, Segmentation Fault, Strack Frame, Pointer, Reference, inspect, syntax bugs, logic bugs, design bugs, memory probes, code walking, stress testing, unit testing, static analysis, runtime analysis, state-verification code, assertions, breakpoints, step, call stack, getattr(), callable() and dump files.
An application can consist of one or more processes. A process is an executing program. A thread is the basic unit to which the operating system allocates processor time. Threads can process stuff from other threads.
The call stack is divided up into contiguous pieces called stack frames, or frames for short; each frame is the data associated with one call to one function. The frame contains the arguments given to the function, the function’s local variables, and the address at which the function is executing.
The technology
pdb, bdb.
Helps you find:
- Typos
- Missing Quotes
- Case Sensitivity
- Pointing to the wrong location
- Naming collisions
- Missing parentheses
- Wrong number of brackets
- Spacing
- Wrong file permissions
- Boolean logic
- Unclosed tags
- Bad logic
- Incorrect username and password
The implementation
Using extra print statements to display the value of your program’s variables is a useful way to figure out what’s going on with your program. You can use the print statement to enumerate the variables. I guess it can work on more complicated programs but the program output could be verbose.
The other way to debug is to use a program that helps you understand whats going on. The core debug trace program is bdb. It has several classes and bdb.Bdb.run looks at:
When the following functions return “frame records,” each record is a tuple of six items: the frame object, the filename, the line number of the current line, the function name, a list of lines of context from the source code, and the index of the current line within that list.
methodList = [method for method in dir(bdb.Bdb) if callable(getattr(bdb.Bdb, method))]
http://docs.python.org/library/inspect.html
http://www.ibm.com/developerworks/library/l-pyint/index.html
http://www.doughellmann.com/PyMOTW/inspect/
http://www.doughellmann.com/PyMOTW/traceback/
http://www.doughellmann.com/PyMOTW/trace/index.html#module-trace
The World's Oldest Intern 