DoAssignment study guide

B4.5 · Debug using traces and variable-state output

Learn to debug using traces and variable-state output through clear examples and targeted practice.

Ontario Grade 11 Computer Science

Software Development

ICS3U study topic B4.5

Debugging means finding and correcting problems in a program. A trace records how relevant variable values change as you follow the program. A debugger is a tool for examining a program as it runs: you can pause at a chosen point, inspect variable values, and continue through later statements while checking how state changes. Together, traces and debugger variable-state output help you locate where behaviour first differs from what you intended. The examples use Python 3 syntax, though classroom languages and debugger controls may differ. All outputs below are derived by tracing the code; none is claimed to come from running it.

What you will learn

Explain how a trace helps locate a program error.
Record how variable values change as statements are followed in order.
Use a debugger to inspect and display variable state at useful points.
Compare traced behaviour with a program’s intended result.

Trace the state, not just the final display

A variable is a named place in a program where a value is stored. Its state at a particular point is the value it holds at that moment. An assignment can replace that value, so later statements use the updated state.

To make a trace, note the input, follow the statements in order, and record the relevant variables after each assignment or decision. At an output statement, use the values held at that point. Compare the trace with what the program was meant to do for that input.

If the final result is wrong, the first traced state that conflicts with the intended behaviour is a useful place to investigate. Check the statement that produced that state and the values it used. This narrows the search without guessing from the final display alone.

Follow statements in order and update the trace after assignments.
Use the current state at each output or decision.
Find the first state that conflicts with the program’s intention.

Use a debugger to inspect variable state

A debugger lets you examine a program’s state as you step through its statements. Set a pause point, often called a breakpoint, on or near a statement you want to investigate. Start the program with a suitable input, and when execution pauses, inspect the displayed values of relevant variables. Continue to the next statement or pause point and check how those values change.

For example, if a running total seems wrong, inspect it before and after the update that changes it. The value before the update shows what the statement starts with; the value after it shows the resulting state. This debugger output provides evidence about what the program is doing at those points.

Choose a pause point to answer a specific question, such as whether an input has the expected value or whether an update has occurred. Record the input, pause point, and variable values in a trace table if that helps you compare the observed states with the intended behaviour. Debugger controls vary, but the purpose is the same: inspect state at selected points while following the program.

Pause at a useful point and inspect relevant variable values in the debugger.
Compare values before and after the statement under investigation.
Use debugger observations to locate a mismatch, then check the responsible statement.

A focused debugging routine

First, state what the program should do for the input you are examining. Next, trace its statements and identify the variables that could explain the behaviour. If the trace suggests a mismatch, use a debugger pause point near the relevant statement and inspect those variables.

Compare the inspected values with the values your trace predicts. If they differ, check the statements already followed and the input supplied. If they agree but the result is still not intended, continue tracing to the next relevant statement. This keeps the investigation tied to evidence rather than assumptions.

Once you identify and correct the problem, trace the affected statements again and check the expected final output against the stated intention. A clear record includes the input, the important state changes, and where the behaviour first differs.

State the intended result for a specific input.
Use traces and debugger variable-state output to investigate the first mismatch.
After a correction, check the relevant state changes and expected result again.

Keep observations relevant

A trace or debugger inspection is most useful when it includes the values that could explain the problem. For a repeated update, record the changing variable after each pass. For a choice, note the condition’s value and the branch followed. Avoid assuming a statement ran: follow the program’s order and its decisions.

When a variable appears wrong, check both the statement that changed it and the values available at that point. A debugger shows state at the pause point, not automatically the history that produced it; use the trace to connect observed values across statements.

Record only the state that helps explain the behaviour.
Use the trace to connect debugger observations from different points.
Follow the program’s order before concluding which statements ran.

Trace for Example 2

Pass	amount	total after update
Before loop	—	0
1	2	2
2	5	7
3	3	10

Worked example

Example 1: Locate an incorrect total

A program should add a delivery fee of 4 to an item price of 12. Its intended total is 16. Trace the code and decide what to inspect in a debugger to find the problem.

Python 3

item_price = 12
total = item_price
total = total - 4
print(total)

Trace the assignments
The input is item_price = 12. The first assignment makes total equal to 12. The next assignment subtracts 4, so total becomes 8. That is the first state that conflicts with the intended total: the fee should be added.
Inspect the update in the debugger
Pause near the update and inspect total and item_price. Before the update, the trace predicts total is 12 and item_price is 12. After the update, it predicts total is 8. These values point to the subtraction statement as the source of the mismatch.
Check the intended update
The update should add 4. With that correction, the traced total becomes 16, matching the stated intention. The expected display from the original code is 8; this is derived from the shown statements, not from a claimed run.

Answer: The original code would display 8 by tracing its assignments. Inspecting total around the update reveals that it subtracts the fee. Adding the fee gives the intended total of 16.

Check: The trace gives total values of 12 before the update and 8 afterward. The mismatch begins at the subtraction.

Worked example

Example 2: Inspect a running total

A program adds the amounts 2, 5, and 3 to a total that starts at 0. Trace the changing state and identify what a debugger should show after each update. Python 3 list indexes start at 0.

Input amounts

Python 3 list indexes are zero-based; the loop uses these values in order.

Python 3

amounts = [2, 5, 3]
total = 0
for amount in amounts:
    total = total + amount
print(total)

Note the starting state
The input list contains 2, 5, and 3 at Python indexes 0, 1, and 2. Before the loop, total is 0. The loop takes each amount in order and adds it to the current total.
Follow each update
After the first update, total is 2. After the second, it is 7. After the third, it is 10. If the debugger pauses after each update, these are the total values to compare with the trace.
Derive the final display
The print statement follows the loop, so it displays the final total, 10. If a debugger observation differs from the trace at a pause point, inspect the update that has just been followed and the amount used there.

Answer: The expected final display is 10. The running total after successive updates is 2, 7, and 10.

Check: The values are added in list order: 0 becomes 2, then 7, then 10.

Worked example

Example 3: Check a choice in the debugger

A program should display "small" for a score below 10 and "large" otherwise. Trace the program for score = 7. Identify what state to inspect if the wrong message appears.

Trace the score choice

For score 7, the shown condition is false, so the else branch is followed.

Python 3

score = 7
if score > 10:
    print("small")
else:
    print("large")

Trace the condition
The input makes score equal to 7. The condition asks whether score is greater than 10. That is false, so the program follows the else branch and displays "large". This conflicts with the intended result, "small".
Inspect the decision point
Pause just before the condition and inspect score. The trace predicts that it is 7. Then follow the decision and check which branch is taken. If score is 7 and the else branch runs, the condition does not express the stated rule.
Compare with the intended rule
The condition should ask whether score is less than 10. For score 7, that condition is true, so the first branch displays "small". This correction follows from the stated rule and the input.

Answer: The original code displays "large" by tracing the false condition. Inspect score at the decision point; for score 7, the condition is unsuitable. Testing whether score is less than 10 gives the intended display.

Check: For the shown condition, 7 is not greater than 10, so the else branch runs.

Common mistakes and how to avoid them

Looking only at the final display and guessing which statement caused it.

Correction: Trace relevant variable values in order and find the first state that conflicts with the intention.

Assuming a variable still has an earlier value after an assignment.

Correction: Update the trace after every assignment; later statements use the current value.

Inspecting an unrelated variable or pausing far from the statement under investigation.

Correction: Pause near the relevant update or decision and inspect the variables that explain it.

Treating a predicted output as though the program was actually run.

Correction: Describe the result as expected output derived by tracing unless the program was genuinely run.

Lesson summary

A trace records relevant variable values as statements are followed in order.
A debugger can pause at selected points so you can inspect variable state and compare it with your trace.
Use the first mismatch to guide investigation, then check the corrected state and expected result.

Check your understanding

Question 1

A program begins with count = 3, then assigns count = count + 2, and displays count. What display follows from the trace?

Show answer and explanation

The assignment uses the current value 3 and replaces it with 5. The display statement then uses 5.

Question 2

You are unsure whether a variable changes at a particular update. Where is a useful place to pause in the debugger?

At the start of an unrelated section
Just after the update being investigated
Only after the program has finished
Before the input is received

Show answer and explanation

Just after the update being investigated

Pausing just after the update lets you inspect the state it produced.

Question 3

A trace shows that a total first becomes incorrect immediately after one assignment. What is the most useful next step?

Inspect that assignment and the values it uses
Change the final display text without checking the update
Assume the input must be incorrect
Record unrelated variables instead

Show answer and explanation

Inspect that assignment and the values it uses

The first incorrect state points to the update that produced it or to the values used by that update.

Key terms

Debugging: Finding and correcting problems in a program.
Trace: A record of program steps and relevant variable values as the steps are followed in order.
Variable state: The value a variable holds at a particular point in a program.
Debugger: A tool for pausing a program and inspecting its state as its statements are followed.

Continue through ICS3U

View the complete ICS3U Ontario Grade 11 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 11 Computer Science (ICS3U), expectation B4.5. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question