OBSERVING FA

CTS A

ND

TRACKIN

G ORIG

INS

CE

N 4

07

2 -

PP

T8

OBSERVING FACTS

Observation determines facts about what has happened in a concrete run, as opposed to deduction that only tells us what might happen.

These techniques include:

- Classical logging

- Interactive Debuggers

-Postmortem debugging

-Visualization and Summarization techniques

PRINCIPLES OF OBSERVATION

Do not InterfereWhatever that is observed should be an effect of the original run –

rather than an effect of the observation. Any observation technique should alter the original run as little as it can.

Know what and when to observeRemember: a Program run is a long succession of huge program states.Observation is only effective if we know what part of the state to

observe and at which moments during the execution to observe.

Proceed SystematicallyDo not observe values at random, rather use a systematic way such as

the scientific method.Always be aware of the current hypothesis, the predictions, and how the

actual observations contribute to the hypothessis.

LOGGING

Logging refers to creating a log while a program is running in order to observe values and witness events as the program runs.

“Printf debugging” can have a few drawbacks including cluttered code, cluttered output, slowdown of the program, and loss of data.

To help fix these problems, it is better to use dedicated logging techniques including:

Use Standard Formats – Standard formats make it easy to search and filter logs

Make logging optional – turn logging off when not being debugged

Allow for variable granularity – it may be helpful to focus on specific events or levels of detail

Be persistent – Allow to re-enable or reuse logging features

Have specific macros - can be turned on or off- for focusing and for creating production code.

LOGGING FRAMEWORK: LOG4J

LOG4J is a popular logging framework for JAVA programs, but is also available for C, C++, C#, PERL, python, RUBY, and Eiffel.

The main idea of LOG4J is to assign each class in a given program an individual or common logger.

Each logger has a level from Debug (least importance) to info, warn, error, and fatal.

The messages are logged by invoking methods such as debug(), info(), warn(), error(), and fatal().

LOG4J EXAMPLE CODE

Demonstration of invoking methods to create logging messages with different priorities.

LOGGING WITH ASPECTS

Logging statements still clutter the source code, so many programmers remove the debugging and logging code once debugging is complete.

Rather than combining actual computational code with logging code, as is the case above, some languages treat these two different types of code as separate entities called aspects.

Each aspect holds only the code for its individual concern, for example, a logging aspect holds the logging code in one syntactical entity called an advice.

In the ASPECTJ language we have to specify the location when an advice is executed. This is done using a point cut – a set of locations (join points) at which the previously cited advice is to be woven into the code.

EXAMPLE OF USING ASPECTS

1. Create an advice : { System.out.println(“Calling Article.buy()”); }

Assume we have an Article class with a buy() method 2. Create a pointcut named

‘buyMethod()’: pointcut buyMethod (): call(public void Article.buy()); 3. Combine into an aspect named LogBuy:

public aspect LogBuy{ pointcut buyMethod(): call(public void Article.buy()); before(): buyMethod() { System.out.println(:Calling Article.buy()”) } } //note: before() indicates that the advice is //called before the actual call.

4. “Weave” aspect into original code: Class Article { public void buy(){ System.out.println(“Entering Article.buy()”); original_buy(); System.out.println(Leaving Article.buy()”); } public void original_buy(){ //Original code of Article.buy() } }

DEBUGGERS

An alternative to logging techniques is to use an external observation tool that hooks into the execution of the program and observes the state at specific moments in time without changing the program code in any way.

The most important observation tools are known as debuggers. Debuggers provide three functionalities to help you observe actual executions:

Execute the program and make it stop on specified conditions

Observe the state of the stopped program

Change the state of the stopped program.

*An example would be the GNU debugger or GDB.*

DEBUGGING WITH GDBInvoked by compiling the program with the –g flag:

Then we must load the program into the debugger:

We predict that a[0]=0 should hold at line 38, so we create a breakpoint at line 38:

Now we can run the program with the breakpoint set:

We can then check the values of individual variables:

EMBEDDED DEBUGGERS

Normally, a debugger invokes the program that is being debugged. A system can be set up to have it call a debugger on itself.

An interpreted language such as PYTHON can have the interactive interpreter invoked, which allows you to explore all of the program’s state at will.

Example: Executing this code obtains:

*Be sure to remove from production code to avoid giving users control of your program.

COCA DEBUGGER

Events and data are characterized by attributes, which can be used in queries to obtain all events or data where the query would be satisfied. A query consists of two parts:

Data queries – A query current_data(attributes) denotes the subset of the execution data in which the given attributes hold

i.e. – current_data(type-int) denotes all data whos type is int

Time queries – A query fget(attributes) denotes the subset of the execution time in which the attributes hold.

i.e. – fget(func=shell_sort) denotes all events in which the current function is shell_sort.

TOOLS FOR OBSERVATION AND DEBUGGING LOG4J – http://logging.apache.org/

Has seen countless enhancements and incarnations since 1996

ASPECTJ – http://www.eclipse.org/aspectj/Aspect oriented programming

GDB - http://www.gnu.org/software/gdb/Mimics Sun’s DBX interactive debugger

DDD – http://www.gnu.org/software/ddd/Front end to GDB and other debuggers

eDOBS – http://www.se.eecs.uni-kassel.de/se/index.php?edobs

Uses UML diagrams for visualization

OMNISCIENT DEBUGGING (ODB)

We want to be able to support the programmer in examining the history of the state without having to restart the entire program.

Execute and record – We can record every single change to every single aspect of the state. This allows the programmer to move through the recording rather than the actual execution.

Step back-and-forth in time – Allowing the execution to be halted and actually stepped forward or backward based on the time stamp for each frame.

Issue event queries – Allow the programmer to jump to specific events rather than having to step back and forth through the entire program.

DYNAMIC SLICING

A dynamic slice encompasses a part of the program that could have been influenced, or been influenced by, a specific variable at some point. This only applies to one single concrete run.

Example: The dynamic slice in b applies to the run in which n and a are read in as 2 and 0, respectively, only.

DYNAMIC SLICE – STEPS TO COMPUTE

First, we would require a trace, or a list of statements in the order they were executed during the concrete run.

In this trace, we record the variables that were read and written as the program was executed.

Also, we introduce a predicate pseudovariable for each predicate that controls execution.

Each of these pseudovariables is written by the statement that controls execution and read by the statements that are controlled.

Now we can compute dynamic slices:

1. For each write w to a variable, assign an empty dynamic slice.

2. Proceed forward through the trace. Whenever the value is written , consider all variables read in that statement. For each variable, consider the line where it was last written and the dynamic slice. Compute the union of these lines and slices and assign it to the write variable.

3. All definitions will be assigned a slice that holds all origins of all values.

DYNAMIC SLICE – EXAMPLE OF CALCULATION

Dynamic Slice:- A dynamic backward

slice only applies to one concrete run.

- More precise than static slice.

- Typically encompasses 5% of program’s statements

- More overhead

- Cannot be reused

Static Slice:- A static backward

slice encompasses the entire program.

- Typically encompasses 30% of program’s statements.

- Can be reused.

DYNAMIC VS. STATIC SLICE

WHYLINE DEBUGGER

“Workspace that Helps You Link Instructions to Numbers and Events”

A debugger where the programmer can ask “Why did my program fail?”

Example is from a PACMAN program.

1. Big Dot.isEaten is set to true2. Therefore, the isEaten variable is

true3. The negation not is false.4. Although Pac is within 2m of

Ghost is true.5. The and conjuction evaluates to

false.6. Therefore, the else clause is

taken.

TRACKING INFECTIONS

The following is a general strategy that combines observation and dependences to narrow down arbitrary infection sites.

1. Start with the infected value as reported by the failure.

2. Follow back the dependences to potential origins.

3. Observe the origins and judge whether the individual origins are infected or not.

4. If you find an earlier infected value, repeat steps 2 and 3 to track its origins.

5. When you find an infected value V where all values that V depends on are sane you have found the defect.

6. Fix the defect and verify that the failure no longer occurs.

TOOLS

ODBThe ODB debugger is available publicly and was developed by

Lewis in 2003. Available at http://www.lambdacs.com/debugger/debugger.html