Browse Prior Art Database

Method for Improving Software Debuggers by Applying Functions from Multimedia Editing Disclosure Number: IPCOM000022399D
Original Publication Date: 2004-Mar-12
Included in the Prior Art Database: 2004-Mar-12
Document File: 1 page(s) / 28K

Publishing Venue



Disclosed is a method for improving the usability of software debuggers by applying known principles from the realm of multimedia editing. Specifically, we disclose a mechanism for allowing slow motion execution of programs while they are executing in the debugger, along with a control for on-the-fly adjustment of the execution delay.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 1

Method for Improving Software Debuggers by Applying Functions from Multimedia Editing

Modern software debuggers provide an excellent mechanism for isolating problems in software by simultaneously viewing source code, memory state, and output. To this end, debuggers traditionally support execution markers called breakpoints which denote predetermined instructions or lines of code at which to temporarily halt execution and examine the memory stack. Once execution has been halted, a debugger acts like a playback device, supporting play (resume execution), pause (halt execution), stop (terminate execution), and advance functions. These advance functions generally allow the software developer to advance one line of source code or instruction at a time. Aditionally, one can specify to step into a function or step over functions for a functional language, like Java. The purpose of these various advance functions is to examine critical sections of code at a granular level. These two traditional debugging approaches, breakpoints and step-through, even in conjunction, have their drawbacks. Since breakpoints must be denoted prior to their execution, a programmer must have a reasonable guess as to the location of the malignant code to be examined before execution. Needless to say, this is not always the easiest thing to ascertain. Once you've guessed a point in the code before the problem occurs, step-through provides a more open ended approach to finding the problem. However, depending on the accuracy of your initial breakpoint, one might need to literally step through hundreds or thousands of lines of code before finding the source of the error. This is both tedious and time consuming, requiring constant...