Advanced Breakpoint-Oriented Debugging

Motivation

To debug a faulty program, a developer needs to set breakpoints at suspicious code locations, first. When the program is suspended at a breakpoint, the developer can analyse whether the current program state is expected according to some requirements.

Setting breakpoints is not a simple task because a set of unrestrictive breakpoints may result in many unnecessary suspensions. Some techniques [2,4] have been used to decrease the effort of setting breakpoints. However, there are some cases that make the existing debugging techniques clumsy. Consider the following examples:

·

Case 1: Finding out where a local variable is set to be null in a method with a long body. First, the developer needs to find out all assignments to this local variable and the set breakpoints to these places. Second, he/she has to observe the value of the local variable when the program is suspended.

·

Case 2: Suspending the program at place A only after place B has been reached. First, the developer needs to set two breakpoints at places A and B. Second, he has to disable the breakpoint at A until breakpoint at B is reached .

·

Case 3: Locating the faulty code indirectly leading to errors. For example, a stream object cannot be read after it has been closed. If this is violated, the developer needs to find out where the stream was closed. Setting a breakpoint at stream.close()requires work for checking whether the stream object is the one leading to the exception later [1].

In the above three cases, the developer is likely to have some redundant suspensions before he/she reaches the position he/she expects. This is mainly because breakpoints cannot exchange information with each other.

Description

The goal of this project is designing and implementing a debugging language which allows:

·

specifying advanced breakpoints for suspending programs at the faulty execution state, and

·

automating some common debugging tasks.

As an example, consider advanced breakpoint for case 3 in pseudo-code below.

In the script, each breakpoint has a unique name and exposes some context values to breakpoints which refer to it. The definitions of bp1 and bp2 are pointcut expressions of AspectJ [3] which is the most popular aspect-oriented programming language. Besides, tasks performed at this breakpoint can also be specified. The figure below gives a crude sample in the form of an Eclipse view.

C:\Users\Haihan\Desktop\Breakpoint view.png

To accomplish this project, you will perform the following tasks:

1.

Designing the grammar for the debugging language;

2.

Implementing the parser for the debugging language (e.g., using the ANTLR parser generator);

3.

Connecting debugging scripts to an aspect-oriented backend (provided);

4.

Implementing the user interface in Eclipse.

References

[1] E. Bodden. Stateful breakpoints: a practical approach to defining parameterized runtime monitors. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, ESEC/FSE ’11, pages 492–495, New York, NY, USA, 2011. ACM.

[2] R. Chern and K. De Volder.Debugging with control-flow breakpoints. In Proceedings of the 6th international conference on Aspect-oriented software development, AOSD ’07, pages 96–106, New York, NY, USA, 2007. ACM.

[3] R. Laddad. AspectJ in Action: Enterprise AOP with Spring Applications. Manning Publications Co., Greenwich, CT, USA, 2009.

[4] R. A. Olsson, R. H. Crawford, and W. W. Ho.A dataflow approach to event-based debugging. Software – Practice and Experience, 21:209–229, 1991.