Software Debugging

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.

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.

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.

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.

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.

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.