Topics in Software Bug Detection

1. Topics in Software Bug Detection Instructor: Murali Krishna Ramanathan

2. What? • Automated bug detection • Design and implementation of algorithms • Emphasis on concurrency • Deadlocks • Race conditions • Atomicity violations • Use Java for explanation • Java Concurrency in Practice – Goetz et al • Discussion of papers • Detection • Reproduction • Prevention • Testing • Miscellaneous

3. Why? • Software testing has limitations • Not scalable • Dependent on quality of test inputs • Human intensive • Challenges • Exciting problems to solve (M.Sc/PhD research topics) • Implementation intensive projects (M.E projects) • Job prospects • Better programmer • New industry • Many companies have program analysis positions • Write analysis tools customized to company’s codebase • Easy grades, less work to finish course requirements - NO

4. When and Where? • Wednesday and Friday • 8 – 9:30 am • CSA 252 • Office hours • 9:30 – 10:30 am • CSA 211 • Subscribe to spring13-310@csa.iisc.ernet.infor announcements • Send email to jags@csa.iisc.ernet.in • Class Webpage: • http://www.csa.iisc.ernet.in/~muralikrishna/teaching/spring2013/e0310.html

5. Course timeline • Understand concepts of concurrency in Java • Jan and part of Feb • Discuss papers • Rest of the semester • Maximum of 4 • Weightage: 15% • Homework Assignments • Jan 22nd and Feb 5th due • Weightage: 15% • Project • Maximum of 3 members in a team • Proposal due by Feb 28th • Final demo due by April 25th. • Weightage: 50% • Emphasis on novelty, applicability to real code

6. Project • Use git to maintain revision history • Contributions evaluated based on the history • No free riders • Use latex for generating project report • Use a build system for development • Java – apache ant, maven, etc • C/C++ -- make • Source code should have sufficient comments • Suggested – use javadoc style comments • All the above will be checked as part of the demo

7. Midterm • End of march • Open book, open notes, open web exam • No need for memorization • Concepts from papers discussed will be part of syllabus

8. Expectation from the course • Understand the complexities of concurrent programming • Ability to implement any program analysis tool • Familiarity with git, latex, {ant, make, maven, …} • Better programmer

9. Background • Single program at a time • Inefficient use of resources • Multiple programs at a time • Process • Resources • Memory • File handles • Security credentials • Communication • Sockets • Signal handlers • Shared memory • Semaphores • files

10. Why multiple programs at a time? • Resource utilization • Wait for I/O by P1 • Let P2 run to effectively use the CPU • Fairness • Users and programs have equal claims • Convenience • Simple to write a dedicate program • Complex to write a program to handle multiple tasks

11. Threads • Light weight process • Share process-wide resources • Memory • File handles • Dedicated • Program counter • Stack • Local variables • Sharing data • Use explicit synchronization • The source of many problems

12. Benefits of threads • Improve performance • Efficient use of resources • E.g., responsiveness of GUI • Exploits multiple processors • Commodity hardware – multiple cores • Single threaded application on a 100 core system • Wastage of 99% of computing power • Simplicity of modeling • Simplicity of writing programs • Straight line code • Web application frameworks • Servlet’s service, doPut, doGetmethods handle multiple requests • Each request executed in a single thread

13. Benefits of threads (continued) • Simplified handling of asynchronous events • Single threaded applications use non-blocking I/O • Complicated and error prone • Each request in its own thread • Synchronous I/O • More responsive user interfaces • Otherwise, frozen UI.

14. Problems with threads • Safety • Unpredictability of results

15. Execution of UnsafeSequence.nextValue

16. Sharing memory address space • Advantages • Convenient • Other inter-thread communication mechanism can be complicated • E.g., counter for the number of web client requests • Downside • Non-sequential control flow • Access needs to be coordinated

17. Thread-safe sequence generator

18. Problems with threads (contd.) • Liveness hazards • Inability to make forward progress • Infinite loops in sequential programs • Other problems in concurrent programs • Deadlock • Livelock • Performance hazards • Overheads associated with context switching • Saving and restoring execution context • Loss of locality • CPU time used on scheduling • Synchronization costs • Inhibits compiler optimizations • Flush/invalidate memory caches • Create synchronization traffic on shared memory bus

19. Why think about thread-safety? • Frameworks create threads • Hence, thread-safety needs to be considered • JVM uses threads • Garbage collection, etc. • AWT and Swing UI • Threads for user interface events • Servlets, RMIs,… • Thread pools are created • TimerTasks • Actions invoked on certain timer events

20. Thread safety • Object’s state stored in state variables • Instance fields • Static fields • Object’s state can be dependent on other object’s state. • Class A { B b;}, class B {int x;} • State variables • Shared – by multiple threads • Mutable – can change value after initialization • Use synchronization to coordinate access to object’s mutable state

21. Shared variables • Multiple threads access the same mutable state variable without synchronization • Program is broken • How to fix it? • Multiple threads -> single thread (do not share) • Mutable -> immutable (do not change state) • Without synchronization -> with synchronization • Design classes for thread-safety • Retrofitting is hard

22. Thread safety and Object-oriented techniques • Encapsulation • Using static fields should be avoided to the extent possible • Make fields private and access using public methods • Immutability • Clear specification of invariants • Pre and post conditions • Thread shared behavior

23. Performance vs Correctness • Encapsulation can conflict with performance • Choose other ways to address performance issues • Between performance and correctness • Choose correctness • Then performance • Losing encapsulation • Thread safety becomes hard, but possible • Maintenance harder

24. What is thread safety? • … can be called from multiple program threads without unwanted interactions between the threads • … may be called by more than one thread at a time without requiring any other action on the caller’s part • Fuzzy definition • Correctness • Class conforms to its specification • Define invariants • Post-conditions describe effects of its operations • Are specifications practical? • Code confidence

25. Thread safety • Class is thread-safe • Behaves correctly when accessed from multiple threads • Independent of scheduling/interleaving of threads • No additional synchronization • No other coordination on part of calling code • Thread safe classes • Encapsulate any needed synchronization • Clients don’t need to provide their own

26. Stateless objects • Always thread safe

27. Objects with states - Atomicity

28. Objects with states - Atomicity • Read-modify-write operation • Incorrect results due to unlucky timing • Race condition • Check-then-act pattern • Do not always cause a problem • Makes debugging even harder

29. Lazy initialization

30. Compound actions • Sequence of operations need to be atomic • Operations on the same state • Example of atomic operations • Check-then-act • Read-modify-write • Thread-safe objects • AtomicLong, AtomicInteger, etc

31. Example using AtomicLong

32. Multiple states in thread-safe object • Update related state variables atomically

33. Intrinsic locks • “synchronized” block (in Java) • Reference to object that will be the lock • Block of code guarded by the lock • synchronized(lock) { … } • Only one thread acquires the lock • Synchronized region is accessible only to the thread that acquired the lock • Ensures atomicity of operations on related state variables

34. Reentrancy • Ability to acquire a held lock by the same thread. Synchronized (lock) { … synchronized(lock) {…}…} • Lock acquisition - increment acquisition count • Another thread acquires lock when count is 0 • Lock release – decrement • Intrinsic locks in Java are reentrant • Non-reentrant locks • Acquisition on a per-invocation basis

35. Guarding state with locks • Synchronization to coordinate access to variable • Everywhere that variable is accessed. • Acquire the same lock • Synchronization needed for read operations as well • If there is at least one write operation • Specify clearly the guarded by relationship • Synchronization does not address all concurrency issues • Atomicity of two synchronized operations • if(!vector.contains(element)) vector.add(element);

36. Performance considerations

37. Liveness and performance • Granularity of synchronized blocks • Too coarse – performance suffers • Too fine – correctness problems • e.g., synchronizing the service() method • Only one request serviced at a time

38. Correct example – Atomicity of operations

39. Design suggestions • Tradeoff between simplicity and performance • Simplicity first • Avoid holding locks for lengthy computations • Network I/O • Console I/O • Loops • Sleep