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 cdgill@cs.wustl.edu Title slide

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

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)

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