Debugging Under Time Pressure

The situation

The judge tells you almost nothing. You get a verdict — wrong answer, time limit exceeded, runtime error — and usually not the input that caused it. You cannot print debugging output to the judge and read it back. So contest debugging is mostly about narrowing the possibilities from your own machine.

Working through a checklist beats staring at the code. Most contest bugs are a handful of recurring mistakes rather than deep logic errors.

Read the verdict first

Each verdict points at a different class of problem.

What each verdict usually means

“Wrong answer on large cases only” is worth calling out. It almost always means overflow. Check every multiplication and every accumulator before looking anywhere else.

The checklist

Printing to standard error

You can print diagnostics without polluting your answer. System.err goes to a different stream, so it does not affect the output the judge compares.

System.err.println("after sort: " + Arrays.toString(a));

When you run locally with output redirected to a file, the diagnostics still appear in your terminal while the answer goes to the file. Remove or leave them — either is safe, since the judge ignores standard error. Leaving them in costs a little time on huge outputs, so remove them if you are near the limit.

Stress testing

This is the technique for a wrong answer you cannot find by inspection. You write a slow-but-obviously-correct solution, generate small random inputs, and compare.

Small is the important part. A failing case with N = 4 can be traced on paper; one with N = 100,000 cannot.

// Generator sketch — writes one random case to stdout
import java.util.*;

public class Gen {
    public static void main(String[] args) {
        Random rnd = new Random(Long.parseLong(args[0]));
        int n = 1 + rnd.nextInt(6);
        StringBuilder sb = new StringBuilder();
        sb.append(n).append('\n');
        for (int i = 0; i < n; i++) {
            sb.append(1 + rnd.nextInt(5)).append(i + 1 < n ? ' ' : '\n');
        }
        System.out.print(sb);
    }
}

Passing the seed as an argument means a failing case is reproducible — you can rerun exactly the input that broke it.

Recursion depth

Java’s default thread stack is small enough that recursion depth around 10,000 to 20,000 can throw StackOverflowError. Graph problems on a path-shaped tree with 200,000 nodes will hit this with a recursive DFS.

Two fixes. Rewrite the traversal iteratively with an explicit stack, or run your solution on a thread with a larger stack:

public class Main {
    public static void main(String[] args) {
        new Thread(null, Main::solve, "main", 1 << 26).start();
    }

    static void solve() {
        // recursive code here — now has a 64 MB stack
    }
}

The iterative rewrite is more robust and is what to reach for if you have time. The thread trick is faster to apply mid-contest.

Next