Software Debugging

We propose a log-based analysis tool for evaluating web application computer system. A feature of the tool is an integration software log with infrastructure log. Software engineers alone can resolve system faults in the tool, even if the faults are complicated by both software problems and infrastructure problems. The tool consists of 5 steps: preparation software, preparation infrastructure, collecting logs, replaying the log data, and tracing the log data. The tool was applied to a simple web application system in a small-scale local area network. We confirmed usefulness of the tool when a software engineer detects faults of the system failures such as " 404 " and " no response " errors. In addition, the tool was partially applied to a real large-scale computer system with many web applications and large network environment. Using the replaying and the tracing in the tool, we found causes of a real authentication error. The causes were combined an infrastructure problem with a software problem. Even if the failure is caused by not only a software problem but also an infrastructure problem, we confirmed that software engineers alone could distinguish between a software problem and an infrastructure problem using the tool.

Debugging large-scale parallel applications is challenging. In most HPC applications, parallel tasks progress in a coordinated fashion, and thus a fault in one task can quickly propagate to other tasks, making it difficult to debug. Finding the least-progressed tasks can significantly reduce the effort to identify the task where the fault originated. However, existing approaches for detecting them suffer low accuracy and large overheads; either they use imprecise static analysis or are unable to infer progress dependence inside loops. We present a loop-aware progress-dependence analysis tool, Prodometer, which determines relative progress among parallel tasks via dynamic analysis. Our fault-injection experiments suggest that its accuracy and precision are over 90% for most cases and that it scales well up to 16,384 MPI tasks. Further, our case study shows that it significantly helped diagnosing a perplexing error in MPI, which only manifested at large scale.

Decompiling is often used in conjunction with recovering lost source code, or in reverse-engineering code when we do not have access to the source. Here we describe a novel use: places where accurate position reporting, even in the presence of optimized code or where source code is not available, could be helpful. Examples include tracebacks, debuggers, core dumps and so on. Also new is using decompilation to assist debugging at run-time. We show how more conventional methods of source-code reporting are vague and ambiguous. Although eecting a pervasive change in a compiler is arduous and error-prone, a decompiler can be developed somewhat independently. However, for the vast number of programming languages, decompilers do not exist. This is true even for dynamic interpreted languages where there is little going on in the way of " compilation. " Traditionally, decompilers are labor intensive and ad hoc, and their construction might also be unfamiliar. So this paper shows how to ameliorate these problems by describing a pipeline for writing decompilers for dynamic languages that we hope will become standard in the same way that the pipeline from the Dragon Book [9] has. Our pipeline diers somewhat from the standard compiler pipeline and from earlier decompiler pipelines [13, 16]. The dierences may lead to further avenues of research and practice. We use a grammar-directed parsing of instructions with an ambiguous grammar to create an AST that, at the top-levels, resembles that of the source-code AST. This is helpful in error reporting. An ambiguous grammar can give an exponential number of derivations on certain likely input sequences, and we describe techniques to deal with this issue. Finally, we describe issues around developing and maintaining a Python bytecode decompiler, which handles the Python language spanning 15 releases over some 20 years. We hope to encourage the incorporation of decompila-tion into tracebacks, debuggers, core dumps, and so on. Reporting a line number as a position in a program can be vague. Consider the following Python code: x = prev[prev[p]] ... If we get the following Python error at runtime: IndexError: list index out of range a line number, and possibly method name or path, will be reported. But which index caused the problem? Or consider possible runtime errors in these lines: x = a / b / c # which divide? # which index? [x[0] for i in d[j] if got[i] == e[i]] return fib(x) + fib(y) # which fib? # code created at runtime exec(a=%s; b=%s % (y, z)) As seen in the last example, there are problems with functions like eval() which evaluate either a string containing a program-language fragment, or which evaluate some intermediate representation of a program such as an Abstract Syntax Tree or a code object. In these cases, the program is created at runtime, either from strings or from method calls which create AST objects and, either way, there is no le containing source code as a stream of characters. The Pos type in Go's AST is more informative in that it encodes the line number, le name and column number all very compactly as an opaque index [11]. Even better, though, would be to extend this to an interval or a beginning and ending position. Go's implementation cleverly takes advantage of a sparseness property: the number of interesting locations in a program, whether a single point or a pair of points, is much smaller than the program's total number of bytes. Therefore it is practical for single integer to index into a small table whose entries have a lot of information. Long experience has shown that trying to get compilers and interpreters to track location correspondences through the compilation process and then save them in the runtime system is an uphill battle. The Go implementers resist extending a Pos type to cover interval positions because of their fear that the line/column approach already slows down compilation.

In this paper using the main feature of our proposed Model in its inflection point, we propose a software reliability growth model, which relatively early in the testing and debugging phase, provides accurate parameters estimation, gives a very good failure behavior prediction and enable software developers to predict when to conclude testing, release the software and avoid over testing in order to cut the cost during the development and the maintenance of the software. Two real world experimental data previously analyzed have been used to compare our proposed Early Estimation Logistic Model effectiveness with several pre-existing models.

Program understanding is an important aspect in Software Maintenance and Reengineering. Understanding the program is related to execution behaviour and relationship of variable involved in the program. The task of finding all statements in a program that directly or indirectly influence the value for an occurrence of a variable gives the set of statements that can affect the value of a variable at some point in a program is called a program slice. Program slicing is a technique for extracting parts of computer programs by tracing the programs' control and data flow related to some data item. This technique is applicable in various areas such as debugging, program comprehension and understanding, program integration, cohesion measurement, re-engineering, maintenance, testing where it is useful to be able to focus on relevant parts of large programs. This paper focuses on the various slicing techniques (not limited to) like static slicing, quasi static slicing, dynamic slicing and conditional slicing. This paper also includes various methods in performing the slicing like forward slicing, backward slicing, syntactic slicing and semantic slicing. The slicing of a program is carried out using Java which is a object oriented programming language.

Fixing failed computer programs involves completing two fundamental debugging tasks: first, the programmer has to reproduce the failure; second, s/he has to find the failure cause. Software debugging is the process of locating and correcting erroneous statements in a faulty program as a result of testing. It is extremely time consuming and very expensive. The term debugging collectively refers to fault localization, understanding and correction. Automated tools to locate and correct the erroneous statements in a program can significantly reduce the cost of software development and improve the overall quality of the software. This paper discusses fault localization, program slicing and delta debugging techniques. It identifies statistical fault localization tools such as Tarantula, GZoltar and others such as dbx and Microsoft Visual C++ debugger that provides a snapshot of the program state at various break points along an execution path. In conclusion we note that most software development companies spend a huge amount of resources in testing and debugging. A lot more research need to be conducted to fully automate the debugging process thereby reducing software production cost, time and improve quality.

Abstract – Since the year 1989, a number of software reliability growth models (SRGMs) with imperfect debugging assumption have been proposed, which include a couple of models that address imperfect debugging integrated with learning phenomenon of the testing team. We propose a NHPP model with shifted Weibull function rate of occurrence of failures (ROCOF) to address imperfect debugging and learning, either occurring separately or in combination thereof. This SRGM is found to provide adequate goodness of fit as well as predictive validity, in addition to fitting failure interval data even when there are reasonable fluctuations in time between failures.

Fixing failed computer programs involves completing two fundamental debugging tasks: first, the programmer has to reproduce the failure; second, s/he has to find the failure cause. Software debugging is the process of locating and correcting erroneous statements in a faulty program as a result of testing. It is extremely time consuming and very expensive. The term debugging collectively refers to fault localization, understanding and correction. Automated tools to locate and correct the erroneous statements in a program can significantly reduce the cost of software development and improve the overall quality of the software. This paper discusses fault localization, program slicing and delta debugging techniques. It identifies statistical fault localization tools such as Tarantula, GZoltar and others such as dbx and Microsoft Visual C++ debugger that provides a snapshot of the program state at various break points along an execution path. In conclusion we note that most software development companies spend a huge amount of resources in testing and debugging. A lot more research need to be conducted to fully automate the debugging process thereby reducing software production cost, time and improve quality.

Decompiling is often used in conjunction with recovering lost source code, or in reverse-engineering code when we do not have access to the source. Here we describe a novel use: places where accurate position reporting, even in the presence of optimized code or where source code is not available, could be helpful. Examples include tracebacks, debuggers, core dumps and so on. Also new is using decompilation to assist debugging at runtime. We show how more conventional methods of source-code reporting are vague and ambiguous. Although effecting a pervasive change in a compiler is arduous and error-prone, a decompiler can be developed somewhat independently. However, for the vast number of programming languages, decompilers do not exist. This is true even for dynamic interpreted languages where there is little going on in the way of “compilation.” Traditionally, decompilers are labor intensive and ad hoc, and their construction might also be unfamiliar. So this paper shows how to ameli...

ABSTRACT SUMMARY Contemporary parallel debuggers allow users to control more than one processing thread while supporting the same examination and visualisation operations of that of sequential debuggers. This approach restricts the use of parallel debuggers when it comes to large scale scientific applications run across hundreds of thousands compute cores. First, manually observing the runtime data to detect error becomes impractical because the data is too big. Second, performing expensive but useful debugging operations becomes infeasible as the computational codes become more complex, involving larger data structures, and as the machines become larger. This study explores the idea of a data-centric debugging approach, which could be used to make parallel debuggers more powerful. It discusses the use of ad hoc debug-time assertions that allow a user to reason about the state of a parallel computation. These assertions support the verification and validation of program state at runtime as a whole rather than focusing on that of only a single process state. Furthermore, the debugger's performance can be improved by exploiting the underlying parallel platform because the available compute cores can execute parallel debugging functions, while a program is idling at a breakpoint. We demonstrate the system with several case studies and evaluate the performance of the tool on a 20 000 cores Cray XE6. Copyright © 2013 John Wiley & Sons, Ltd.

ABSTRACT Goel proposed generalization of the Goel–Okumoto (G–O) software reliability growth model (SRGM), in order to model the failure intensity function, i.e. the rate of occurrence of failures (ROCOF) that initially increases and then decreases (I/D), which occurs in many projects due to the learning phenomenon of the testing team and a few other causes. The ROCOF of the generalized non-homogenous poisson process (NHPP) model can be expressed in the same mathematical form as that of a two-parameterWeibull function. However, this SRGM is susceptible to wide fluctuations in time between failures and sometimes it seems unable to recognize the I/Dpattern ofROCOFpresent in the datasets and hence does not adequately describe such data. The authors therefore propose a shifted Weibull function ROCOF instead for the generalized NHPP model. This modification to the Goel-generalized NHPP model results in an SRGM that seems to perform better consistently, as confirmed by the goodness of fit statistic and predictive validity metrics, when applied to failure datasets of 11 software projects with widely varying characteristics. A case study on software release time determination using the proposed SRGM is also given.

Computer software has progressively turned out to be an essential component in modern technologies. Penalty costs resulting from software failures are often more considerable than software developing costs. Debugging decreases the error content but expands the software development costs. To improve the software quality, software reliability engineering plays an important role in many aspects throughout the software life cycle. In this paper, we incorporate both imperfect debugging and change-point problem into the software reliability growth model(SRGM) based on the well-known exponential distribution the parameter estimation is studied and the proposed model is compared with the some existing models in the literature and is find to be better.

This paper describes a study of Java program debugging using a multiple window software debugging environment (SDE). In this study we have replicated an earlier study by Romero et al.(2002a, 2002b, 2003), but with the difference of using both the Restricted Focus Viewer and the eye tracking equipment to track the visual attention of the subjects. The study involved ten subjects debugging short Java programs using the SDE. The SDE included three different representations of the Java programs, those of the program source ...

Large community clusters are becoming common in universities and other organizations due to the benefits they provide to participating researchers in terms of reduced operational costs and a bigger resource pool. However, effective management, and diagnosing failures and performance issues in these clusters are challenging tasks due to the diversity of workloads run by users from various domains and experience levels. Many users who use these clusters have very less experience in computing and hence often face performance issues — leading to resource wastage. In this paper, we study these dynamics in one of the largest university-wide community clusters. We perform in-depth analysis of library and application usage patterns, job failures and performance issues. Further, we introduce a set of novel analysis techniques that can be used to identify hidden trends and diagnose job failures in compute clusters in general. We provide concrete recommendations for the cluster administrators and present case studies highlighting how such information can be used to proactively solve many user issues, ultimately leading to better quality of service.