COTS Challenges for Embedded Systems

1
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_at_cs.wustl.edu
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 youre
  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 youll 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