Search 250 million research papers

Debugging

2006

Cited by 0

Debugging

Thomas Sterling, Matthew Anderson, Maciej Brodowicz · Elsevier eBooks · 2018

Cited by 0

Relative Debugging: A New Debugging Paradigm

David Abramson, Rok Sosič · 1994

Conventional debuggers provide primitives for controlling one computer process at the time. Relative debuggers extend the capabilities of conventional debuggers by being able to control two or more processes at once and by providing primitives for comparing the states of these processes. The processes can run on the same computer or on different computers, connected by a network. The processes can differ in their source programming language, in their mode of execution (sequential, parallel, vector), or in implementation details. One of the processes usually serves as a reference version which produces the desired results. The execution of the other process is compared to the reference version in order to find discrepancies. We introduce the concept of relative debugging and present a prototype implementation called Guard. Guard implements basic primitives for relative debugging. It is built on top of our portable debugging interface which provides a debugging platform for heterogeneous...

Cited by 2

Live debugging : a new debugging experience

Abhishek Jaiswal · DR-NTU (Nanyang Technological University) · 2014

Understanding and working with unfamiliar code is often a challenge of software integration or debugging. This process requires awareness of the program state and the call hierarchy, which introduces significant cognitive overhead. With the advent of new and innovative debugging such as back in time debugging, debugging with visualization and interrogative debugging users have even more powerful ways of exploring and investigating source code.
\n
\n
\n
\nIn the meantime, this increased complexity can lead to overwhelming cognitive demands that can stress the user. As such, it is vital to study them from various alternate points of view. One important point of view looks at the degree to which an interface supports developers and beginners in understanding the execution flow of their programs. These debugging techniques can be extended to develop new methods for program visualization to help beginners in learning how to program. The aim is to enhance the learner’s understanding of the different aspects of the program execution.
\n
\n
\n
\nThis project aims to propose and design a prototype, which gives the user control over program visualization and allows the user to focus on memory and variable allocation as well as providing them visual representation of object. The user can see the program steps from different viewpoints by going forward and backwards in time and it’s easy to use especially for the user. Thus the author will propose and design a program visualization tool that will use new visualizations to aid flow comprehension and reduce cognitive overhead.

Cited by 0

Out-Of-Place debugging: a debugging architecture to reduce debugging interference

Matteo Marra, Guillermo Polito, Elisa Gonzalez Boix · The Art Science and Engineering of Programming · 2018

Context Recent studies show that developers spend most of their programming time testing, verifying and debugging software. As applications become more and more complex, developers demand more advanced debugging support to ease the software development process.

Cited by 5Open access

Debugging debugging information using dynamic call trees

J. Ryan Stinnett, Stephen Kell · Research Portal (King's College London) · 2026

Debugging tools rely on compiler-generated metadata to present a source-language view, but current compilers often throw away or corrupt debugging information in optimised programs.Attempts to test debugging information are confounded by ad-hoc limitations of the debug info formats and a lack of clarity on whether the compiler or the format is to blame for any given loss.Adopting the "residual program" conceptual view of debug info, we conduct a study of the quality of debugging information in respect of the source-level dynamic call trees it can recover.We compare the trees recovered from optimised and unoptimised versions of the same program, producing a classification of the observed divergences.For each class, we analyse whether format or compiler is to blame and identify specific ways to address these defects.We also validate our classification across a larger collection of well-known codebases.

Cited by 0Open access

Proactive Debugging

Jack Ganssle · Elsevier eBooks · 2004

Cited by 1

Program debugging

H. E. Kulsrud, Robert M. Blazer, Hermann H. Goldstine et al. · 1974

The computing community is now concerned with the cost in time and money consumed by the debugging process. In spite of advances, such as proving program correctness, use of higher level languages and new methods for structuring programs, the problem remains. The panelists will consider many phases of the debugging activity as it exists today, giving their views on current and proposed tools and techniques.

Cited by 0

Assertion Debugging

Darin Dillon · Apress eBooks · 2003

Debug asserts are a tough sell. Lots of developers have never heard of them, so they don’t use them. Lots of other developers have heard of them, but don’t understand them and use them incorrectly. And some developers have watched the second group misuse asserts for so long that they’ve decided asserts are evil and should never be used at all. That’s unfortunate, because when used correctly, asserts are one of the most powerful and cost-effective tools in your arsenal for detecting bugs and pinpointing their source.

Cited by 0

Practical Debugging

Deisz, Kevin · TIB KMO / FLOWWORKS GmbH · 2017

People give ruby a bad reputation for speed, efficiency, weak typing, etc. But one of the biggest benefits of an interpreted language is the ability to debug and introspect quickly without compilation. Oftentimes developers reach for heavy-handed libraries to debug their application when they could just as easily get the information they need by using tools they already have. In this talk you will learn practical techniques to make debugging easier. You will see how simple techniques from the ruby standard library can greatly increase your ability to keep your codebase clean and bug-free.

Cited by 0Open access

Debugging Tactics

Bill Blunden · Apress eBooks · 2012

The general predicament is as old as programming itself: an application is malfunctioning and it’s your job to fix it. Naturally, the best person to fix an application is the original author. The majority of maintenance engineers, however, don’t have this distinction. Topically, their boss hands them a program that someone else wrote three years ago, and they have to start from the very bottom of the learning curve.

Cited by 0

Debugging Scripts

Hanaan Rosenthal · Apress eBooks · 2004

Debugging your scripts is not something you do as the final step of script writing. You should do your debugging while you’re writing the script, every step of the way. As your mom always told you: it is better to clean up as you go along.

Cited by 0

Fullstack Debugging

Shai Almog · Apress eBooks · 2023

The definition of fullstack is shifting like quicksand to match whatever the observer considers to be the stack. I’ve seen some definitions that include OPS aspects into the mix. A more common definition follows the process of writing both the frontend and the backend.

Cited by 0

Manual Debugging

H. Kopetz · 1979

Cited by 0

Debugging Shells

Yogesh Babar · Apress eBooks · 2020

As of now, we know that initramfs has bash built in, and we have used it from time to time through rd.break hooks. This chapter’s aim is to understand how systemd provides us with a shell inside an initramfs. What are the steps that have to be followed, and how can one use it more effectively? But before that, let’s recap what we have learned so far about the debugging and emergency shells of initramfs.

Cited by 0

Debugging Ada

Bruegge, Bernd · KiltHub Repository · 2018

Computer Science Department

Cited by 0Open access

Logical Debugging

Yuh-jeng Lee, Nachum Dershowitz · 1993

this paper, user input is shown in bold face and system generated output is shown in typewriter type font):

Cited by 0

Debugging methodology

Wayne C. Gramlich · 1983

Two sessions were held on the general topic of debugging methodology. Both were moderated by R. Stockton Gaines. During the first session five speakers presented short talks on their workshop submissions. Each talk was followed by a brief question and answer period. The format of the second session was that of an open discussion. The talks presented in the first session have been briefly summarized. The remaining notes of these two sessions have been arranged topically rather than chronologically.

Cited by 3Open access

Debugging Scripts

Mark Conway Munro · Apress eBooks · 2021

When a simple script encounters an error, it is relatively easy to troubleshoot. As a database grows more complex, troubleshooting rapidly becomes more challenging. Script calls initiated by users, event triggers, other scripts, and external systems form complex interwoven hierarchical execution stacks. Scripts can change found sets, switch layouts, and open new windows, creating a complex web of interconnected interface contexts. When something breaks, it is often difficult to even know which script caused the error, not to mention knowing where, why, and under what contextual conditions the problem occurred. To ease this burden, modern development environments like FileMaker include a debugger.

Cited by 0

Debugging Inputs

Kirschner, Lukas, Soremekun, Ezekiel, Zeller, Andreas · CISPA Helmholtz Center · 2020

Program failures are often caused by invalid inputs, for instance due to input corruption. To obtain the passing input, one needs to debug the data. In this paper we present a generic technique called ddmax that (1) identifies which parts of the input data prevent processing, and (2) recovers as much of the (valuable) input data as possible. To the best of our knowledge, ddmax is the first approach that fixes faults in the input data without requiring program analysis. In our evaluation, ddmax repaired about 69% of input files and recovered about 78% of data within one minute per input.

Cited by 0Open access