Topics in Software Bug Detection Instructor: Murali Krishna Ramanathan

Download Topics in Software Bug Detection Instructor: Murali Krishna Ramanathan

Post on 23-Dec-2015




0 download

Embed Size (px)


<ul><li> Slide 1 </li> <li> Topics in Software Bug Detection Instructor: Murali Krishna Ramanathan </li> <li> Slide 2 </li> <li> 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 </li> <li> Slide 3 </li> <li> 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 companys codebase Easy grades, less work to finish course requirements - NO </li> <li> Slide 4 </li> <li> When and Where? Wednesday and Friday 8 9:30 am CSA 252 Office hours 9:30 10:30 am CSA 211 Subscribe to for announcements Send email to Class Webpage: /e0310.html </li> <li> Slide 5 </li> <li> 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 22 nd and Feb 5 th due Weightage: 15% Project Maximum of 3 members in a team Proposal due by Feb 28 th Final demo due by April 25 th. Weightage: 50% Emphasis on novelty, applicability to real code </li> <li> Slide 6 </li> <li> 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 </li> <li> Slide 7 </li> <li> Midterm End of march Open book, open notes, open web exam No need for memorization Concepts from papers discussed will be part of syllabus </li> <li> Slide 8 </li> <li> 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 </li> <li> Slide 9 </li> <li> 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 </li> <li> Slide 10 </li> <li> 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 </li> <li> Slide 11 </li> <li> 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 </li> <li> Slide 12 </li> <li> 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 Servlets service, doPut, doGet methods handle multiple requests Each request executed in a single thread </li> <li> Slide 13 </li> <li> 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. </li> <li> Slide 14 </li> <li> Problems with threads Safety Unpredictability of results </li> <li> Slide 15 </li> <li> Execution of UnsafeSequence.nextValue </li> <li> Slide 16 </li> <li> 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 </li> <li> Slide 17 </li> <li> Thread-safe sequence generator </li> <li> Slide 18 </li> <li> 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 </li> <li> Slide 19 </li> <li> 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 </li> <li> Slide 20 </li> <li> Thread safety Objects state stored in state variables Instance fields Static fields Objects state can be dependent on other objects 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 objects mutable state </li> <li> Slide 21 </li> <li> Shared variables Multiple threads access the same mutable state variable without synchronization Program is broken How to fix it? Multiple threads -&gt; single thread (do not share) Mutable -&gt; immutable (do not change state) Without synchronization -&gt; with synchronization Design classes for thread-safety Retrofitting is hard </li> <li> Slide 22 </li> <li> 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 </li> <li> Slide 23 </li> <li> 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 </li> <li> Slide 24 </li> <li> 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 callers part Fuzzy definition Correctness Class conforms to its specification Define invariants Post-conditions describe effects of its operations Are specifications practical? Code confidence </li> <li> Slide 25 </li> <li> 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 dont need to provide their own </li> <li> Slide 26 </li> <li> Stateless objects Always thread safe </li> <li> Slide 27 </li> <li> Objects with states - Atomicity </li> <li> Slide 28 </li> <li> 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 </li> <li> Slide 29 </li> <li> Lazy initialization </li> <li> Slide 30 </li> <li> 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 </li> <li> Slide 31 </li> <li> Example using AtomicLong </li> <li> Slide 32 </li> <li> Multiple states in thread-safe object Update related state variables atomically </li> <li> Slide 33 </li> <li> 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 </li> <li> Slide 34 </li> <li> 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 </li> <li> Slide 35 </li> <li> 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); </li> <li> Slide 36 </li> <li> Performance considerations </li> <li> Slide 37 </li> <li> 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 </li> <li> Slide 38 </li> <li> Correct example Atomicity of operations </li> <li> Slide 39 </li> <li> Design suggestions Tradeoff between simplicity and performance Simplicity first Avoid holding locks for lengthy computations Network I/O Console I/O Loops Sleep </li> </ul>