Bringing Back-in-Time Debugging Down to the Database

With back-in-time debuggers, developers can explore what happened before observable failures by following infection chains back to their root causes. While there are several such debuggers for object-oriented programming languages, we do not know of any back-in-time capabilities at the database-level. Thus, if failures are caused by SQL scripts or stored procedures, developers have difficulties in understanding their unexpected behavior. In this paper, we present an approach for bringing back-in-time debugging down to the SAP HANA in-memory database. Our TARDISP debugger allows developers to step queries backwards and inspecting the database at previous and arbitrary points in time. With the help of a SQL extension, we can express queries covering a period of execution time within a debugging session and handle large amounts of data with low overhead on performance and memory. The entire approach has been evaluated within a development project at SAP and shows promising results with respect to the gathered developer feedback.Comment: 24th IEEE International Conference on Software Analysis, Evolution, and Reengineerin

PECCit: An Omniscient Debugger for Web Development

Debugging can be an extremely expensive and time-consuming task for a software developer. To find a bug, the developer typically needs to navigate backwards through infected states and symptoms of the bug to find the initial defect. Modern debugging tools are not designed for navigating back-in-time and typically require the user to jump through hoops by setting breakpoints, re-executing, and guessing where errors occur. Omniscient debuggers offer back-in-time debugging capabilities to make this task easier. These debuggers trace the program allowing the user to navigate forwards and backwards through the execution, examine variable histories, and visualize program data and control flow. Presented in this thesis is PECCit, an omniscient debugger designed for backend web development. PECCit traces web frameworks remotely and provides a browser-based IDE to navigate through the trace. The user can even watch a preview of the web page as it\u27s being built line-by-line using a novel feature called capturing. To evaluate, PECCit was used to debug real-world problems provided by users of two Content Management Systems: WordPress and Drupal. In these case studies, PECCit\u27s features and debugging capabilities are demonstrated and contrasted with standard debugging techniques

Tracing and Debugging of Lazy Functional Programs - A Comparative Evaluation of Three Systems

In this paper we compare three systems for tracing and debugging Haskell programs: Freja, the Redex Trail System and Hood. We identify the similarities and differences of these systems and we evaluate their usefulness in practice by applying them to a number of small to medium programs in which errors had deliberately been introduced

Multiple-View Tracing for Haskell: a New Hat

Different tracing systems for Haskell give different views of a program at work. In practice, several views are complementary and can productively be used together. Until now each system has generated its own trace, containing only the information needed for its particular view. Here we present the design of a trace that can serve several views. The trace is generated and written to file as the computation proceeds. We have implemented both the generation of the trace and several different viewers

Towards a debugging tutor for object-oriented environments

Programming has provided a rich domain for Artificial Intelligence in Education and many systems have been developed to advise students about the bugs in their programs, either during program development or post-hoc. Surprisingly few systems have been developed specifically to teach debugging. Learning environment builders have assumed that either the student will be taught these elsewhere or thatthey will be learnt piecemeal without explicit advice.This paper reports on two experiments on Java debugging strategy by novice programmers and discusses their implications for the design of a debugging tutor for Java that pays particular attention to how students use the variety of program representations available. The experimental results are in agreement with research in the area that suggests that good debugging performance is associated with a balanced use ofthe available representations and a sophisticated use of the debugging step facility which enables programmers to detect and obtain information from critical momentsin the execution of the program. A balanced use of the available representations seemsto be fostered by providing representations with a higher degree of dynamic linkingas well as by explicit instruction about the representation formalism employed in the program visualisations