Concurrent Bug Patterns and How to Test Them

Concurrent Bug Patterns and How to Test Them Myeong-Sin, Kang Dept. of Informatics, GNU. 2013. 1. • by EitanFarchi, YardenNir, Shmuel Ur

Contents • Introduction • Concurrent Bug Patterns • Code Assumed to Be Protected • Interleavings Assumed to Never to Occur • Blocking or Dead Thread Bug Pattern • New Timing Heuristics for Finding Concurrent Bug Patterns • Deducing Concurrent Bug Patterns from Design Patterns • Conclusion

Introduction • A bug taxonomy for sequential programs was used to motivate test techniques. • but, no test techniques were developed based on the taxonomy for concurrent programs. • This paper describes and categorizes a detailed taxonomy of concurrent bugs. • Then, Use the taxonomy to create new heuristics for testing.

Concurrent Bug Patterns (1) • For a concurrent program P… • I(P): the set of interleavings that can occur in P • C(P): the set of interleavings under which the program is correct. C(P) = the “programmerview” of P • Concurrent Bug Pattern: a interleavings in I(P)-C(P) I(P)-C(P) = the “bugpatterngap”

Concurrent Bug Patterns (2) • For example, • Consider a nonatomic, two byte, integer operation… • two threads executing as x=257; || x=0; “programmer view” “actually…” thread1: thread2: thread1: thread2: x=257; x=0; x[0]=1; // 1 x[1]=1; // 256 x=0; final value: final value: x=257 x=0 or x=257 x=0 x=256 or or bug pattern gap

Concurrent Bug Patterns (3) • high level categories of concurrent bug patterns: • Code Assumed to Be Protected  When a code segment is mistakenly assumed to be undisturbed by other threads. • Interleavings Assumed Never to Occur  A result of the mistaken assumption that a certain execution order of concurrent events is impossible. • Blocking or Dead Thread Bug Pattern  When a code segment is mistakenly assumed to be nonblocking.

Code Assumed to Be Protected (1) • Nonatomic Operations Assumed to Be Atomic • In Java, “x++” for a class instance field is thought to be protected. • However, “x++” is translated to three bytecode instructions… • move the current value of x, heap  thread’s local area copy of x • increment the thread’s local area value by one • update the heap value of x • A Context switch may occur after each of stages.  unprotected

Code Assumed to Be Protected (2) • Two-Stage Access Bug Pattern • Sometimes a Sequential flow needs to be protected. • For example, • 1st operation: Accessing the table A to translate from key1  key2 • 2nd operation: key2 is used to access the table B • Accesses to each tables are protected. however, a context switch may occur between the access to the table A and the table B  unprotected

Code Assumed to Be Protected (2) • Wrong Lock or No Lock • For example, • 1st thread executes synchronized(o){ x++} • 2nd thread executes x++; • A possible final value for x is can be 1  “synchronized(o){ x++} ” is actually not protected.

Code Assumed to Be Protected (2) • Double-checked Locking (DCL) • For example, //DCL Pattern public static Singleton getInstance(){ if( singleton == null ){ synchronized(Singleton.class){ if( singleton == null )singleton = new Singleton(); } } return singleton;}  while Singleton() is executing, singleton may not be null

Interleavings Assumed Never to Occur • The sleep() Bug Pattern • The programmer adds sleep() in a parent thread right after child thread creation to wait until the child is initialized. • However, there is no guarantee that the child thread finishes the initializing before the parent thread wake up. • Losing a Notify Bug Pattern • If a notify() is executed before its corresponding wait(), the notify() has no effect, and the code executing wait() might not be awakened.

Blocking or Dead Thread Bug Pattern • A “Blocking” Critical Section Bug Pattern • A thread is assumed to eventually return control but it never does.  causing the system to hang. • The Orphaned Thread Bug Pattern • In a master-slaves system, if the master thread terminates abnormally, the remaining threads may continue to run, awaiting more input from the master.  causing the system to hang.

New Timing Heuristics for Finding Concurrent Bug Patterns • Timing heuristics are used to increase the probability that known kinds of concurrent bugs will occur. • At runtime, the runtime controller is given control before and after a concurrent event is executed. • The controller can use Java primitives such as sleep() and yield() to change the order of concurrent event execution. • Use ConTest tool for instrumentation and testing.

Deducing Concurrent Bug Patterns from Design Patterns • Concurrent design patterns can be used to deduce typical concurrent bug patterns. • For Example, • The token design pattern: • After a resource transfer of the from “x.r = y.s”, if the resource is a token, then it occurs an error because y still points to the same resource “s”. • This bug is Associated with “code assumed to be protected”

Conclusion • This paper categorized a taxonomy of concurrunt bug patterns. • Testing techniques can be enhanced using the bug taxonomy.

Concurrent Bug Patterns and How to Test Them