Topics in Software Bug Detection

Instructor: Murali Krishna Ramanathan

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

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

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.in for announcements Send email to jags@csa.iisc.ernet.in

Class Webpage: http://www.csa.iisc.ernet.in/~muralikrishna/

teaching/spring2013/e0310.html

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

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

Midterm End of march Open book, open notes, open web exam

No need for memorization Concepts from papers discussed will be part of

syllabus

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

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

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

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

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, doGet methods handle multiple requests

Each request executed in a single thread

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.

Problems with threads Safety

Unpredictability of results

Execution of UnsafeSequence.nextValue

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

Thread-safe sequence generator

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

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

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

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

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

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

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

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

Stateless objects Always thread safe

Objects with states - Atomicity

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

Lazy initialization

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

Example using AtomicLong

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

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

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

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);

Performance considerations

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

Correct example – Atomicity of operations

Design suggestions Tradeoff between simplicity and performance

Simplicity first Avoid holding locks for lengthy computations

Network I/O Console I/O Loops Sleep