Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Debugging: Tips and ToolsAlso, Aloha15-441 RecitationWednesday, February 7th, 2007AlohaRadio protocolPure/Slotted, whats the difference? Why bother?ChalkboardOverviewWhat is debugging? Strategies to live (or at least code) by.Tools of the tradegdbsmart loggingelectric fenceGood tip sheet from last semesters TA at :http://www.cs.cmu.edu/~dga/debugging.pdfWhat is debugging?You tell me! Everybody writes codes with bugs.What debugging have you needed to do already on the smtp project? Things to think about:- What caused the bug?- How did you end up finding it?- How could you have avoided the bug in the first-place?Debugging PhilosophyGuiding Steps:1) Think about why you believe the program should produce the output you expected.2) Make assertions until you understand how your view differs from the computer’s.Coder: code will produce output X …Computer: code will produce Z….Requirements for DebuggingWHAT program behavior to look for?Sometimes this is nearly free.... (e.g., compiler error, or segfault)Sometimes it is the hardest part.... (e.g., logic bugs, race conditions)How to easily expose information to test hypothesis?gdb, logging, strace, ethereal....Strategies to Live By...Debugging is part art, part science. You’ll improve with experience….… but we can try to give you a jump-start!Strategy #1: Debug with PurposeDon't just change code and “hope” you'll fix the problem! Instead, make the bug reproducible, then use methodical “Hypothesis Testing”:While(bug) {Ask, what is the simplest input that produces the bug?Identify assumptions that you made about program operation that could be false.Ask yourself “How does the outcome of this test/change guide me toward finding the problem?”Use pen & paper to stay organized!}Strategy #2: Explain it to Someone ElseOften explaining the bug to “someone” unfamiliar with the program forces you to look at the problem in a different way. Before you actually email the TA’s:Write an email to convince them that you have eliminated all possible explanations....Strategy #3: Focus on Recent ChangesIf you find a NEW bug, ask: what code did I change recently?This favors:- writing and testing code incrementally-using 'svn diff' to see recent changes-Lession: Check in often! -regression testing (making sure new changes don't break old code).strategy #4: When in doubt, dump stateIn complex programs, reasoning about wherethe bug is can be hard, and stepping through ina debugger time-consuming. Sometimes its easier to just “dump state” and scan through for what seems “odd” to zero in on the problem. Example: Dumping all packets using tcpdump.Strategy #5: Get some distance...Sometimes, you can be TOO CLOSE to the code to see the problem. Go for a run, take a shower, whatever relaxes you but let's your mind continue to spin in the background.strategy #6: Let others work for you!Sometimes, error detecting tools make certain bugs easy to find. We just have to use them.Electric Fence or Valgrind: runtime tools to detect memory errorsExtra GCC flags to statically catch errors:-Wall, -Wextra, -Wshadow, -Wunreachable-code-Entire page of warnings goodness at gcc.gnu.org/onlinedocs/gcc4.1.1/WarningOptions.htmlStrategy #7: Think AheadBugs often represent your misunderstanding of a software interface.Once you've fixed a bug:1) Smile2) Think about if the bug you fixed might manifest itself elsewhere in your code (a quick grep can help).3) Think about how to avoid this bug in the future (maybe coding 36 straight hours before the deadline isn't the most efficient approach....)Tools of the TradeDifferent bugs require different tools:1) Program crashes with segfault -> gdb2) Hard to reproduce or highly complex bugs-> logging & analysis3) Program hangs waiting for network traffic -> tcpdump / etherealGDB: Learn to Love itRun a program, see where it crashes, or stop it in the middle of running to examine program state. Two ways to run:gdb binary (to run binary inside of gdb)gdb binary core-file (to debug crashed program)GDB CommandsControlling Executionrun <cmd-line args>break <func>step nextcontrol-c Getting Infobacktraceprint <expr>info localslistup/downTons of commands: google : gdb command listWatches!GDB Tricks & TipsRemember: always compile with -g, and no optimizations. If your not getting core files, type: ‘unlimit coredumpsize’ You can use GDB in emacs! (see slides at end)Smart LoggingUse a debug macro that you can easily turn off to suppress output just by changing one line.(example posted online) Often smart to create generic log functions like dumpSMTPMessage() or dumpRoutingPacket()A tool like 'strace' or 'ktrace' may be able to log easily read information for free!Electric FenceAdds run-time checks to your program to find errors related to malloc.e.g.: writing out of bounds, use after free...just compile your programs using -lefenceDemo Alternative: Valgrind finds more memory errors, but is VERY slow.ValgrindJust type valgrind <program name> -axFor example valgrind smtpsend -axDemonstrationTime for a demonstrationUsing GDB in EmacsThe commands/keystrokes to make it happen:1. Compile with -g and *NO* -O2 or -O32. build with a "make"3. emacs smtpsend.c (or any other source file)4. CTRL+x and then '3' (open a right frame)5. CTRL+x and then 'o' (switch cursor to right frame)6. ESC+x and then "gdb" and hit enter7. Type in the name of your binary *only*, like "smtpsend" and hit enter8. Set any break points you want, then type "run params ...", forexample "run andrew.cmu.edu" and hit enter9. Use GDB with your code!! (next, step, print, display...)GDB in EmacsNote the arrow in the left source file window shows the line being executed!That’s
View Full Document