Debugging UC Berkeley Fall 2004, E77 Copyright 2005, Andy Packard. This work is licensed under the Creative Commons Attribution-ShareAlike License. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Debugging your programs When you write a program, there are almost always errors. Three different types of errors are –Syntax errors: you simply have typed an illegal expression, independent of the values of the variables in the expression. Matlab will catch this once you try to run the program (even without executing your code). Matlab will usually issue a pretty clear error message, and you are directed to the problem. These types of bugs are easy to fix. –Run-time errors: logic errors that result in an illegal expression for specific values of the data (harder to fix) Matlab will catch this when you run the code. At the line containing the illegal expression, Matlab will issue an error. You can insert some “printouts” right before the expression to see what the variables are, and try to understand what is the problem –Do the variables have incorrect values? Or –The expression is indeed not correct. –Logic errors that result in the program executing completely, but the answer that they return is incorrect (hardest to fix).

Finding run-time errors (bugs) The most primitive way to debug a program is to –Work out (by “hand”) what the intermediate values of variables should be for a specific case –Remove the trailing semicolons ; from your program, so that Matlab will display the intermediate results –Call your program, and compare the printouts (your program) to your hand-calculations, and try to see where things start to differ.

Finding run-time errors (bugs) A better (but ultimately the same) way is to –Work out (by “hand”) what the intermediate values of variables should be for a specific case –Insert the command keyboard at some point in your program. This is called “setting a breakpoint” –Run the program –When execution gets to the keyboard line program execution is temporarily stopped the Command window appears, the prompt is K>> control is at the keyboard (ie., you can type), and the scope of variables is the function workspace (you are “in” the function at the line of code where the keyboard command is) –Type expressions at the K>> prompt (variables to see what their values are, upcoming expressions to see what their values will be, etc). You are a detective at this point. –Type K>> return (resume execution) or K>> dbquit (exit)

Single-line stepping through an m-file Use dbstep to step through an M-file a line-at-a-time To execute the next line of code, type K>> dbstep To execute the next 6 lines of code, type K>> dbstep 6 To execute code until another m-file function is called, and then to “stop inside” that function at its first line, type K>> dbstep in To execute code until the m-file function exits, and then to stop inside the m-file function that called it, type K>> dbstep out After any of these, the “instruction pointer” moves to the next line of code which has not executed.

Stopping in an M-file Use dbstop to stop in an M-file at a certain line if a condition is true. To stop in loancalc at line 11 if the variable G is less than 1 K>> dbstop in loancalc at 11 if G<1 This sets a conditional breakpoint. When execution gets to line 11, Matlab will evaluate the expression G<1. –If it is true, then execution will stop, the K>> prompt will appear in the Command window, and so on… –If it is false, then execution will continue on as if no breakpoint was set.

Clearing breakpoints All breakpoints can be cleared with the command >> dbclear all You can also selectively clear breakpoints that were created with dbstop. See >> help dbstop >> help dbclear for more information.

Using dbup and dbdown Normally at a breakpoint –execution is temporarily stopped –the K>> prompt appears in the command window –the variables in the function’s workspace can be examined. The command dbup changes the scope of visible variables to the caller’s workspace. K>> % examine variables in function’s workspace K>> dbup K>> % examine variables in caller’s workspace K>> dbdown K>> % examine variables in function’s workspace

Seeing all of the function instances Use dbstack to see the list of all function instances that are running. –The top line gives the function instance where the dbstack command occurred. –The (n+1)’th line is the function instance of the function which called the function instance listed on the n’th line.

Profiling your code When running a program, Matlab can keep track of –How many times a single line is executed –How many times a function is called –How much total time is spent executing a specific line of code –How much time is spent running a specific function These pieces of information can often help you discover bottlenecks that are slowing your code down, and surprising calls that you thought would happen less/more (ie.,perhaps a bug). >> profile on >> myprogram >> profile report