Patent Application
20130247007
Not Applicable.
Not Applicable.
The present invention relates to the electrical, electronic and computer arts, and, more particularly, to application development and the like.
Breakpoints are an important tool used in debugging software. However, not all executions of a given line of source code are equally interesting to the debugging task at hand. For example, a common library subroutine may be called many times from many different contexts during a program's execution. Some of these contexts may be entirely unrelated to the developer's current focus. This requires the developer to repeatedly examine the program state, and ask the debugger to continue execution until a relevant execution context occurs.
As a result, debugging complex scenarios may be further facilitated by the use of a conditional breakpoint, with which a Boolean predicate is associated. This predicate is evaluated each time the corresponding location is reached during program execution. If the predicate evaluates to true, the debugger stops at the breakpoint; if not, program execution continues.
Principles of the invention provide techniques for making debugger behavior conditional on past program state. In one aspect, an exemplary method includes the step of setting, for a debugger, a debugger variable associated with: at least one location within a program to be debugged; and at least one expression that is valid within a scope of the at least one location. Further steps include setting a breakpoint associated with a location within the program; upon encountering the at least one location of the debugger variable during a current run of the program, computing a value of the at least one expression with which the debugger variable is associated, and assigning the value of the at least one expression with which the debugger variable is associated to the debugger variable; and, upon encountering the location of the breakpoint during the current run of the program, operating the debugger in at least one of a first manner and a second manner, depending on the value of the debugger variable, the first manner being different than the second manner.
As used herein, “facilitating” an action includes performing the action, making the action easier, helping to carry the action out, or causing the action to be performed. Thus, by way of example and not limitation, instructions executing on one processor might facilitate an action carried out by instructions executing on a remote processor, by sending appropriate data or commands to cause or aid the action to be performed. For the avoidance of doubt, where an actor facilitates an action by other than performing the action, the action is nevertheless performed by some entity or combination of entities.
One or more embodiments of the invention or elements thereof can be implemented in the form of a computer program product including a computer readable storage medium with computer usable program code for performing the method steps indicated. Furthermore, one or more embodiments of the invention or elements thereof can be implemented in the form of a system (or apparatus) including a memory, and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, one or more embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include (i) hardware module(s), (ii) software module(s) stored in a computer readable storage medium (or multiple such media) and implemented on a hardware processor, or (iii) a combination of (i) and (ii); any of (i)-(iii) implement the specific techniques set forth herein.
Techniques of the present invention can provide substantial beneficial technical effects. For example, one or more embodiments may provide one or more of the following advantages:
These and other features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
As noted, breakpoints are an important tool used in debugging software. However, not all executions of a given line of source code are equally interesting to the debugging task at hand. For example, a common library subroutine may be called many times from many different contexts during a program's execution. Some of these contexts may be entirely unrelated to the developer's current focus. This requires the developer to repeatedly examine the program state, and ask the debugger to continue execution until a relevant execution context occurs.
As a result, debugging complex scenarios may be further facilitated by the use of a conditional breakpoint, with which a Boolean predicate is associated. This predicate is evaluated each time the corresponding location is reached during program execution. If the predicate evaluates to true, the debugger stops at the breakpoint; if not, program execution continues.
However, conditional breakpoints in the current state of the art are limited in that they examine only the program's current state, and moreover, limited to examining the data visible in the context of the source location with which the breakpoint is associated. As a result, they are applicable only if detecting whether a given execution of a given statement is relevant can be determined by examining solely the present state of the contextually visible data. In some cases, this is either difficult or impossible.
One general case is when a program executes in several stages, and the programmer wants to have the debugger break at a routine in some stages of execution but not in others. For example, consider a program that first initializes a framework, and then makes calls to some routine. Suppose further that the framework itself makes calls to that same routine during initialization. A breakpoint set within the routine would trigger each time that routine is called, including during the initialization phase, even though that is not a context of interest.
Another general case is when the programmer wants to have the debugger break at a routine only following one or more events that occur somewhere else in the code. This can be especially frustrating when debugging graphical user interfaces (GUIs), as the system may keep switching focus between the application and the debugger. For example, say the programmer wants to have the debugger break when the mouse is moved, but only in a certain region R of the GUI after some popup has been opened and then closed. This sort of dependency is virtually impossible to express in current debuggers.
One or more embodiments advantageously provide a mechanism whereby the debugger allows the user to create a set of “debugger variables,” each of which is associated with:
(a) a unique identifier (which may be a user-supplied name),
(b) a source location, and
(c) an expression (which might be a Boolean predicate, for example).
Each time the source location (b) is encountered during a program's execution, the debugger evaluates the expression (c), and sets the value of debugger variable with identifier (a) to the result of the expression's evaluation. Thus, the value of a given debugger variable is defined to be the value of the associated expression (c) as evaluated when the program most recently encountered location (b).
Such debugger variables can be used to modify the debugger's behavior in various ways, including:
The debugger system may provide a “debugger variables” view for these debugger variables.
To address the first example above, the user can create a debugger variable, frameworkInitialized, and set it to FALSE at the start of the program and to TRUE right after the framework is initialized, and make the breakpoints in the routine be conditional on this debugger variable.
To address the second example, the user can create a debugger variable, regionEntered, and set its value when encountering mouseOver( . . . ) and mouseOut( . . . ) events for Region R, and another debugger variable, popupClosed, and set its value to TRUE when the popup is closed. Once these debugger variables have been defined, they can be combined in a conditional breakpoint expression to get the debugger to break as required in the second example.
Alternatively, the user can simplify the conditional breakpoint expression by using a debugger variable whose condition depends on the value of another debugger variable. In the case of the second example, the user can create a debugger variable regionEnteredAndPopupClosed and set its value to the value of regionEntered when the popup is closed. Thus the value of regionEnteredAndPopupClosed is TRUE only when regionEntered is TRUE, and the condition in the conditional breakpoint need only depend on the value of regionEnteredAndPopupClosed.
In one or more embodiments, the debugger variable mechanism can be implemented via a set of objects within the debugger, as described above. For each debugger variable, the debugger sets a breakpoint, which may be hidden from the user's view, at the associated source location. Each time this breakpoint is reached, the debugger evaluates the associated predicate, and sets the value of the debugger variable accordingly. When evaluating a condition that refers to the debugger variable, the debugger substitutes the value obtained by the most recent evaluation of the associated predicate.
Whenever the running program encounters the location dv_loci of a debugger variable DVi, as seen at S106, the debugger evaluates the debugger variable's expression dv_expri and assigns it as the value of DVi, as seen at S107. Whenever the running program encounters the location bp_loci of a conditional breakpoint BPi, as seen at S108, the debugger evaluates the conditional breakpoint's condition bp_condi, at S109, and, based on its value, in decision block S110, if true, pauses the program (returning to S101), or, if false, keeps the program running (returning to S105). The condition bp_condi may refer to the values of one or more debugger variables, which is how debugger variables affect the behavior of conditional breakpoints.
To relate debugger variables (DVs) to breakpoints (BPs), the condition expressions in the conditional breakpoints condi may refer to the values of one or more debugger variables value(idj).
In
Elements S305, S306, and S309 comprise variable values stored in a register or possibly persisted in a non-volatile memory. Block S308 operates in a manner somewhat analogous to block S307. When the program reaches a certain point, the debugger variable is evaluated and stored for later use. In one or more embodiments, debugger S301 comprises a conventional debugger modified as follows: a debugger variable evaluation module (typically a segment of code) is added, which, when it is determined that a debugger variable location has been reached, will evaluate the current value of the debugger variable and store the result in debugger variable location S309; furthermore, breakpoint evaluation module S307 and/or user interface S310 as the case may be are modified so that they can be made aware of the value(s) of the debugger variable(s) and act accordingly.
Thus, one or more embodiments provide an enhanced debugging method including a debugger performing steps of setting at least one condition variable; evaluating a condition by comparing the condition to the appropriate set condition variable during program execution; and triggering actions based on the evaluating. Some embodiments further include setting one or more breakpoints in the program. In some cases, the debugger performs steps at a breakpoint of: pausing the program; evaluating an associated predicate; and setting a value of the condition variable.
In one or more instances, evaluating a condition includes substituting the value obtained by a most recent evaluation of the associated predicate. In some embodiments, triggering an action includes at least one of allowing the program to continue execution, controlling information display, and the like. In some embodiments, each condition variable is associated with a unique name, a given source location, and a Boolean predicate.
One or more embodiments deal with capturing past program state. One or more embodiments do not involve an event-processing engine, but rather augment the debugger with conditional variables, which are both set and interpreted by the debugger. One or more instances provide conditional variables that can capture arbitrary aspects of the state, as well as affecting other behaviors of the debugger (besides deciding whether or not to take breakpoints). One or more instances relate to affecting debugger behavior.
Given the discussion thus far, it will be appreciated that, in general terms, an exemplary method, according to an aspect of the invention, includes the step S102 of setting, for a debugger, a debugger variable DVi. The debugger variable is associated with at least one location dv_loci within a program to be debugged, and at least one expression dv_expri that is valid within the scope of the location. This step can be carried out, for example, with user interface S310. A further step S103 includes setting a breakpoint BPi. The breakpoint is associated with a location bp_loci within the program. This step can also be carried out, for example, with user interface S310.
As seen at step S106, upon encountering the at least one location dv_loci of the debugger variable during a current run of the program (step S105), a further step S107 includes computing the value of the at least one expression dv_expri with which the debugger variable is associated, and assigning the value of the at least one expression with which the debugger variable is associated to the debugger variable DVi. This step can be carried out, for example, with debugger variable evaluation module S308.
In this regard, with respect to the language “debugger variable is associated with at least one location dv_loci within a program to be debugged, and at least one expression dv_expri that is valid within the scope of the location,” this is to state that a generalization is possible in some instances, namely, to associate with each debugger variable one or more {source-location, expression} pairs. When encountering any of the locations associated with a given debugger variable, the value of the debugger variable is updated to the value of the expression corresponding to that source location. Furthermore in this regard, using a debugger variable with multiple {source-location, expression} pairs can be emulated in some instances by using multiple debugger variables, each with a single {source-location, expression} pair), but the former approach may let the developer express things more simply in certain cases.
As seen at step S108, upon encountering the location bp_loci of the breakpoint BPi during the current run of the program, a further step includes operating the debugger in at least one of a first manner and a second manner, depending on the value of the debugger variable. The first manner is different than the second manner. This step can be carried out, for example, with breakpoint evaluation module S307, if the different behavior is pausing/not pausing, or with user interface S310, if the different behavior relates to display.
In some cases, in the step of setting the breakpoint, the breakpoint is a conditional breakpoint further associated with a condition expression bp_condi that refers to the value of the debugger variable, and a further step S109 includes computing a value of the condition expression that refers to the value of the debugger variable.
In some instances, the first manner comprises pausing (S101) the program at the location with which the conditional breakpoint is associated; and the second manner comprises continuing the program without pausing (S105)—see decision block S110.
In some embodiments, the condition expression is Boolean such that the first manner comprises pausing the program at the location with which the conditional breakpoint is associated, if the value of the condition expression has a first one of two logical values; and the second manner comprises continuing the program without pausing if the value of the condition expression has a second one of the two logical values. Thus, with regard to such cases, referring to decision block S110, a further step includes pausing the program at the location with which the conditional breakpoint is associated, if the value of the condition expression has a first one of two logical values (e.g., TRUE), as per the “true” branch of block S110 looping back to state S101; and continuing the program without pausing if the value of the condition expression has a second one of the two logical values (e.g., FALSE), as per the “false” branch of block S110 looping back to state S105. Of course, the condition expression could be inverted and the program paused if FALSE and continued if TRUE.
In some cases, the condition expression bp_condi refers to the value of the debugger variable and also to the value of at least one additional debugger variable. See, e.g., Second example case I above.
In some instances, the expression dv_expri with which the debugger variable is associated refers to the value of at least one additional debugger variable. See, e.g., Second example case II above.
In some cases, an additional step includes providing a system. The system includes at least one distinct software module. Each of the distinct software module(s) is embodied, in a non-transitory manner, on a computer-readable storage medium. The distinct software module includes a debugger module S301. In such cases, the step S102 of setting the debugger variable is carried out by the debugger module executing on at least one hardware processor; the step S103 of setting the breakpoint is carried out by the debugger module executing on the at least one hardware processor; the step S107 of computing the value of the at least one expression with which the debugger variable is associated is carried out by the debugger module executing on the at least one hardware processor; and the step of operating the debugger in the at least one of a first manner and a second manner is carried out by the debugger module executing on the at least one hardware processor.
Note that the current run of the program typically includes the main program module(s) S302 executing on the at least one hardware processor.
In some embodiments, in the providing step, the debugger module includes at least a portion of an integrated development environment (IDE). In such cases, behavior of the debugger module in the integrated development environment, when paused at a breakpoint, can be affected by the value of the debugger variable (or variables). Furthermore, in such cases, the affected behavior can determine which program variables of the program to be debugged are displayed; the affected behavior can determine how program variables of the program to be debugged are displayed; and/or the IDE can provide a view of debugger variables (for example, on interface S310).
In some cases, the debugger module S301 includes a plurality of distinct software sub-modules (which may also be referred to herein as modules; the notation sub-modules is adapted for formal reasons to refer to components of a previously-recited module). Each of the distinct software sub-modules is embodied in a non-transitory manner on the computer-readable storage medium. The distinct software sub-modules include a user interface submodule S310, a debugger variable evaluation submodule S308, and a breakpoint evaluation submodule S307. The step S102 of setting the debugger variable is carried out by the user interface submodule executing on the at least one hardware processor; the step S103 of setting the breakpoint is carried out by the user interface submodule executing on the at least one hardware processor; the step S107 of computing the value of the at least one expression with which the debugger variable is associated is carried out by the debugger variable evaluation submodule executing on the at least one hardware processor; and the step of operating the debugger in the at least one of a first manner and a second manner is carried out by at least one of the breakpoint evaluation submodule and the user interface submodule executing on the at least one hardware processor, as described elsewhere herein. Any of the other modules and/or submodules shown in
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
One or more embodiments of the invention, or elements thereof, can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps.
One or more embodiments can make use of software running on a general purpose computer or workstation. With reference to
Accordingly, computer software including instructions or code for performing the methodologies of the invention, as described herein, may be stored in one or more of the associated memory devices (for example, ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (for example, into RAM) and implemented by a CPU. Such software could include, but is not limited to, firmware, resident software, microcode, and the like.
A data processing system suitable for storing and/or executing program code will include at least one processor 402 coupled directly or indirectly to memory elements 404 through a system bus 410. The memory elements can include local memory employed during actual implementation of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during implementation.
Input/output or I/O devices (including but not limited to keyboards 408, displays 406, pointing devices, and the like) can be coupled to the system either directly (such as via bus 410) or through intervening I/O controllers (omitted for clarity).
Network adapters such as network interface 414 may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
As used herein, including the claims, a “server” includes a physical data processing system (for example, system 412 as shown in
As noted, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Media block 418 is a non-limiting example. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It should be noted that any of the methods described herein can include an additional step of providing a system comprising distinct software modules embodied on a computer readable storage medium; the modules can include, for example, any or all of the elements depicted in the block diagrams and/or described herein; by way of example and not limitation, modules and/or sub-modules corresponding to the components in
In any case, it should be understood that the components illustrated herein may be implemented in various forms of hardware, software, or combinations thereof; for example, application specific integrated circuit(s) (ASICS), functional circuitry, one or more appropriately programmed general purpose digital computers with associated memory, and the like. Given the teachings of the invention provided herein, one of ordinary skill in the related art will be able to contemplate other implementations of the components of the invention.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
