Advanced debugging
Hunting a hard bug methodically: hypotheses, minimal reproducible example, git bisect, watchpoint, concurrent access, memory leak, thread and heap dumps.
- 26 cards
- 5 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- The numbers
- Scenarios
A few cards from the deck
Minimal reproducible example: what is it?
Show the answer
The smallest program that still triggers the bug: everything that can be removed without making it vanish has been.
Each line removed rules out suspects. It also serves as a regression test and can be passed on without the rest of the application.
Commit 1 is good and commit 16 is bad. At most how many commits must be tested, with git bisect, to find the first faulty commit?
- 4
- 2
- 8
- 15
Show the answer
4
Each try halves the interval: 16, 8, 4, 2, 1. That is log2(16) = 4. Testing commits one by one would take up to 15.
To automate the search, run … with a script: an exit code … marks the commit good, and … makes it skipped.
Show the answer
To automate the search, run git bisect run with a script: an exit code 0 marks the commit good, and 125 makes it skipped.
Codes from 1 to 127, except 125, mark the commit bad. 125 is for a commit that does not build and cannot be judged.
Watchpoint: what is it?
Show the answer
A program stop triggered as soon as a variable or a memory area is modified, wherever in the code.
You no longer look for the faulty line: you let the debugger point to it, even when the write comes from somewhere unexpected, such as a stray pointer.