CSE 403 Topic: Profiling, Debugging and Tracing

Once you know that there's a bug in your code, figuring out which part of your code is responsible is often a difficult process. Debuggers and profilers are tools that help you find correctness and performance bugs, respectively, in your code.

Traditional debuggers allow the programmer to instrument their code with "breakpoints" - places in the program where the program should stop so that the programmer can inspect the program's state.

Profilers typically instrument the program to report which instruction is being executed on some interval. The programmer can then look for parts of the program that are being executed more or less often than expected.

Tracing and monitoring is an important part of production engineering practice. By tracing the latency, monitoring the resource usage and collecting the error rate, engineers can know whether there are undetected software defects and whether the user experience is good.

Some common debuggers, profilers and tracing system are:

• gdb
• Valgrind
• Prometheus
• Linux perf

Interesting resources:

• Time travel debugging: https://en.wikipedia.org/wiki/Time_travel_debugging
• Excellent blog post on the weaknesses of debuggers: https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/
• A modern profiler recently open-sourced by Uber: https://eng.uber.com/jvm-profiler/
• USE method
• End-to-End Tracing: Adoption and Use Cases

Project ideas:

• why is print-line debugging still common when debuggers exist? Is there a good way to combine the advantages of both?
• when you are debugging, what information do you need that isn't readily available in a traditional debugger like gdb? Can you imagine a tool that collects that information?