1. Testing and Debugging Concurrent Code
E81 CSE 532S: Advanced Multi-Paradigm Software Development
Testing and Debugging Concurrent Code
Chris Gill
Department of Computer Science and Engineering
Washington University in St. Louis
Title slide

2. Concurrency Related Bugs
Deadlock occurs when a thread never unblocks
Complete deadlock occurs when no thread ever unblocks
Blocking I/O can be problematic (e.g., if input never arrives)
Livelock is similar but involves futile effort
Threads are not blocked, but never make real progress
E.g., if a condition never occurs, or with protocol bugs
Data races and broken invariants
Can corrupt data, dangle pointers, double free, leak data
Lifetime of thread relative to its data also matters
If thread exits without freeing resources they can leak
If resources are freed before thread is done with them (or even gains access to them) behavior may be undefined

3. Locating Concurrency Related Bugs
Inspection can be useful but easily misses subtle bugs
Any possible sequence of relevant actions may matter
Explanation/modeling can be even more powerful
Speculate about how different sequences can manifest
Even (or especially) unlikely ones: what if another thread…?
Gain experience with different races, deadlocks
Try those on for size with respect to code you’re testing
E.g., ABA issues, circular waits, etc.
Hypothesize, predict, instrument & observe, repeat
The scientific method is the most powerful debugging tool
Develop concurrency related regression test suites
Invest in testing harnesses that drive event sequeneces, etc. (e.g., boost statecharts may let you automate some of this)

4. Design for Testability
Consider doing formal modeling of concurrency
E.g., for model checking of temporal or timed temporal logic
Good tools exist to help with this (SPIN, UPPAAL, IF, etc.)
At least consider what tests you’ll run as part of design
Can help you avoid concurrency design mistakes initially
Can help you maintain regression tests as code evolves: e.g. how likely will you spot a newly introduced race in old code?
Design for pluggable concurrency
Single threaded vs. logically vs. physically concurrent
A pluggable scheduler and modular units of work can help
Taken to its extreme do combination simulation testing
Combining all of the above potentially lets you explore, test, and then reproduce different concurrency scenarios reliably