Prioritized debugging of an error space in program code

A computer system has an input system and an output system. Program code to be debugged has a plurality of program code statements. The input system is utilized to indicate an error variable in the program code. The error variable has an error value that differs from a desired value. An error set of the error variable is obtained, which is a subset of the statements in the computer readable code. Each statement in the error set is relationally connected to the error variable. A priority value is given to each statement in the error set. The priority values indicate a computed probability that the associated statement is an error source of the error variable. Finally, the output system is used to present each statement in the error set in an ordered manner according to the priority values.

BACKGROUND OF INVENTION

1. Field of the Invention

The present invention relates to debugging software. Specifically, the present invention discloses a system and method that algorithmically determines the probability of a line of source code as being an error source in the error space of a variable.

2. Description of the Prior Art

Software is becoming increasingly common across a broad spectrum of fields. Correspondingly, a number of software tools and packages have come onto the market to help with the automation and computerization of tasks that were once done manually. Many of these tools are robust, presenting themselves as highly specific programming languages to flexibly accomplish tasks in a narrow field. This results in more people than ever, who never initially considered themselves as programmers, being faced with the task of debugging faulty code. An excellent example of this is in the field of integrated circuit (IC) development. Nowadays, ICs are being designed not on paper, but coded as instructions in a hardware development language (HDL). These circuits are not tested and debugged with physical elements, but virtually by way of simulators that execute the HDL code. When the HDL code is considered bug-free, and hence the under-lying circuits that are described by this code are considered error-free, the HDL code is “compiled” into the corresponding circuit elements for wafer manufacturing. More than ever, circuit designers are not tinkering with physical elements, but instead with lines of computer-readable and executable code that simulates these elements. A direct effect of this is that, to improve efficiency, means must be found to help programmers quickly and easily locate the sources of bugs in computer code.

The tried-and-true method for finding bugs in computer code is by tracing and breakpoints. A programmer sets breakpoint conditions that cause the computer to stop executing at a particular line of code, under particular memory read/write conditions, or by other methods. The most common is simply to set a breakpoint at a line of code. Every time the computer reaches the breakpoint, execution of the program stops and the programmer can use a debugger to check the contents of the memory and processor. Typically, breakpoints are set at the end of loops to determine if the loop of code has executed as desired. Breakpoints are also frequently set at the beginning of a subroutine when the subroutine is known to be behaving incorrectly. The programmer can then trace through the execution of each line of code in the subroutine individually to find the related bug.

All of this is extremely time consuming. Computer code frequently runs into the thousands of lines, and many of these lines may be individually executed thousands of times before a bug manifests itself. In turns of time resources spent debugging, it is invariably inefficient, and sometimes impossible, for a programmer to manually trace through code to find a bug.

SUMMARY OF INVENTION

It is therefore a primary objective of this invention to provide a method and system that presents lines of code to a programmer in an ordered fashion indicating which of the lines of code are most likely to be a source of error for a variable in a program.

The present invention, briefly summarized, discloses a method and corresponding system for assisting with debugging program code in a debugger on a computer system. The computer system has an input system and an output system. The program code has a plurality of program code statements. The input system is utilized to indicate an error variable in the program code. The error variable has an error value that differs from a desired value. An error set of the error variable is obtained, which is a subset of the statements in the computer readable code. Each statement in the error set is relationally connected to the error variable. A priority value is given to each statement in the error set. The priority values indicate a computed probability that the associated statement is an error source of the error variable. Finally, the output system is used to present each statement in the error set in an ordered manner according to the priority values.

It is an advantage of the present invention that by presenting the statements in the error set in a ordered manner according to the priority values, a user debugging the code can quickly refer to those lines of code that are deemed to be the most probable sources of the bug. Debugging times are thereby considerably shortened.

DETAILED DESCRIPTION

Please refer toFIG. 1.FIG. 1shows an example of hardware development language (HDL) code. The method of the present invention is particularly well suited for the debugging of HDL code, as HDL code is executed repetitively in a series of discrete execution cycles. Each execution cycle may be thought of as a machine clock tick for the circuitry that the HDL code is used to simulate. As the circuitry should have well-defined outputs for each clock tick, the variables that represent circuit outputs may be checked at each execution cycle against desired results to look for bugs. In this manner, a person debugging the code may learn that a bug has cropped up in a particular execution cycle. The method of the present invention shall be explained by way of a specific example of incorrect code.

As can be seen, the HDL code ofFIG. 1comprises a plurality of program code statements1. Program code statements1can be logically grouped together to form subroutines2. All of this should be obvious to one reasonably skilled in the art of computer programming and debugging. It should be noted that the subroutines2each begin with a program code statement1that starts “always @( . . . )”. This indicates that the program code statements1within the subroutine2are always executed with each simulated clock tick. The program code ofFIG. 1may be thought of as being enclosed within a large execution loop (analogous to “for” statements in C, Pascal, BASIC, etc.), each iteration of the loop corresponding to a circuit clock cycle, and the subroutine statements2are executed with each iteration of the loop to simulate a circuit clock tick.

The circuit has a plurality of primary inputs, as defined by program code statement1awith variables PI1, PI2, PI3and PI4, and a plurality of primary outputs as defined by program code statement1bwith variables PO1and PO2. The primary inputs are manipulated in each execution cycle to generate the primary outputs. Generally speaking, when testing the accuracy of the program code, with each execution cycle the values of the primary output variables are compared against their desired values, as required by a circuit specification. If, in an execution cycle, a primary output variable does not agree with its desired value, then a bug is said to be in the program code, and the variable associated with the primary output is the error variable. The execution cycle in which the error occurs is termed the error cycle.

Simply identifying that a bug exists is the first step in removing the bug from the computer code. The second step is to find the source of the bug, and it is the object of the present invention to provide aide with respect to this second step. The sources of bugs are multifarious, and the symptoms of a bug may not appear for many execution cycles, under highly specific input conditions. Consider, for the following example, the computer code ofFIG. 2in conjunction with that ofFIG. 1.FIG. 2shows computer code much like that ofFIG. 1, but with a bug in program code statement3b.FIG. 1depicts a correct program code statement3a: “w2=PI4|PI1;”. InFIG. 2, the program code statement3bcontains an incorrect line, “w2=PI4;”. That is, the variable w2is directly assigned the value of the primary input PI4, rather than being assigned the logical OR of the primary inputs PI4and PI1. Because the variable w2is not a primary output variable, the effect of this bug may not become immediately obvious. That program code statement3bhas a bug may only become clear when the program code ofFIG. 2is run and compared against desired results. It should be noted that, inFIGS. 1 and 2, the symbol “&” indicates a logical AND, and “^” a logical XOR. The symbol “|” is, as indicated in the above, a logical OR.

For the following example, suppose that in the first execution cycle the primary inputs are set as follows: PI1=1, PI2=1, PI3=1, PI4=0

For the circuit represented by the code ofFIG. 2, the primary outputs have the following desired values: PO1=1, PO2=1

When the code is executed, after the first execution cycle, the following values are found for the variables PO1and PO2: PO1=1, PO2=1

Thus, the desired values of the primary outputs matches the actual values of the related primary output variables, and the bug in the program code statement3bpasses by undetected after the first execution cycle. For all intents and purposes, the computer code ofFIG. 2is bug-free for the first execution cycle.

In this case, the bug in program code statement3bfinally presents itself. The actual output of the primary output variable PO1, a value of 1, differs from its desired output of 0 that is required by the circuitry specifications. PO1is thus the error variable, and execution cycle number3is the error cycle.

Please refer toFIG. 3in conjunction withFIGS. 1 and 2.FIG. 3is a perspective view of a computer system10that utilizes the method of the present invention. The computer system10includes a display12as an output system, and a mouse14with a keyboard16as an input system. To find which of the program code statements1are most likely to be responsible for the bug, a user first uses the mouse14or keyboard16to indicate one or more error variables. In this case, the error variable would be PO1. The user also indicates which execution cycle is the error cycle. In this case, the error cycle is cycle number3. The computer system10then implements the following method to present on the display12an ordered list of the most likely lines of program code statements1that are responsible for the bug.

To begin, an error set of the error variable is found. To do this, the relation space of the error variable is used, which is all program code statements1that are relationally connected to the error variable. This relation space can be termed the error space of the program code, for it includes all program code statements1that are directly or indirectly responsible for setting the value of the error variable (i.e., PO1). In the worst case, the error space could include the entirety of the program code. In the simplest case, the error space would include only one program code statement1. Using the present example, as noted, the error variable is PO1. The most obvious program code statement that is relationally connected to PO1is program code statement26. It is noted that program code statement26involves variable w1, whose value is assigned at program code statement22. What value is assigned to PO1depends on the “case” statement in program code statement25. Program code statement25, in turn, relies on the variable sell, which is assigned in program code statement20. Continuing this process, it is clear that a rapid fan-out of inter-related variables causes PO1to be relationally connected to almost every line in the program code ofFIG. 2. Indeed, the final error space is found to be (indicated by item numbers): Error space={20,21,22,24,25,26,27,28,29,30,31,3b}

About the only program code statement that is not relationally connected to PO1is program code statement23, which simply assigns a value to primary output variable PO2. For these purposes, the relatively simple input/output variable declarations of1aand1bare ignored, as well as block nesting identifiers “begin”1cand “end”1d, as they can have no direct influence on the value of error variable PO1.

It would help considerably if the error space could be narrowed down. Ideally, this should be done without removing the program code statement that is responsible for the bug, i.e., program code statement3b. To narrow the error space, and thus generate the error set, the execution set is considered. This execution set is the set of all program code statements that are executed in the error cycle. Indicated with item numbers, the execution set for the present example is: Execution set={20,21,22,23,24,25,27,29,30,3b}

To obtain the error set, the relation space for the error variable is considered only in the context of the execution set. That is, only program code statements in the execution set that are relationally connected to the error variable are used to generate the error set. It is noted, for example, that program code statement26is not in the execution set, and thus is not relationally connected to the error variable PO1with respect to the executions set, though it is in the error space. To generate the error set, each item in the execution set is checked for relational dependency with the error variable PO1, in much the same manner that the error space is found. The error set, as a sub-set of the execution set, is found to be: Error set={20,21,24,25,27,29,30,3b}

Note, in particular, that program code statements22and23, which are both in the execution set, are not in the error set. Program code statement23is not in the error set because it was never in the error space to begin with, and thus could not possibly be relationally connected to the error variable PO1. On the other hand, program code statement22is in the error space, yet it is not in the error set. This is because program code statement22assigns a value to variable w1and, within the error cycle, the value of w1is never used in any way to influence the value of the error variable PO1. Program code statement22is thus not relationally connected to the error variable PO1within the context of the execution set. The program code statements in the error set are considered the most likely candidates for the source of the bug. The primary objective of the present invention is to prioritize these program code statements as more or less likely sources of the bug, and thereby more quickly speed a programmer to the target source of the bug.

To obtain a computed probability that a program code statement in the error set is the source of the bug, previous execution cycles are used in conjunction with one or more correct variables. A correct variable is any variable whose value matches its desired value in the error cycle. For the present example, the primary output variable PO2is considered as a correct variable. The correct variable is preferably a primary output variable, or one with many relational dependencies with the error variable. The number of execution cycles that are used before the error cycle may be configured as deemed best. Generally speaking, the more execution cycles used, the better the results of the prioritization. However, more execution cycles can lead to slower processing times, and heavier demands on computer resources. For the present example, the first two execution cycles are considered. That is, the first two execution cycles before the error cycle are considered, with PO2as the correct variable, since PO2has a value of one in the error cycle that agrees with its desired value of one.

Initially, a set of priority values is created and initialized so that each member of the set is zero. Each priority value in the set of priority values directly corresponds to one of the program code statements in the error set, and indicates a computed probability that the related program code statement is an error source (i.e., bug) for the error variable. For the present example, a higher priority value will indicate that the related program code statement in the error set is a less likely source of the bug. We thus have: Error set:{20,21,24,25,27,29,30,3b} Priority values:{0,0,0,0,0,0,0,0}

The first execution cycle is considered. A first sensitized set for the correct variable in the first execution cycle is obtained. A sensitized set is analogous to the error set, and is found in much the same manner, except that the correct variable PO2is considered, and statements executed in the first execution cycle are considered. To put this another way, the error set above is simply a sensitized set for the error variable PO1in the error cycle, i.e., the third execution cycle. However, only program code statements in the error set are permitted in a sensitized set. Thus, to build a sensitized set, three parameters must be known: the variable to be considered, the execution cycle in which the executed program code statements are parsed to determine if they are relationally connected to the variable under consideration, and the error set. With the present example, a first execution set is constructed, which contains all of the program code statements executed in the first execution cycle (indicated by item numbers): First execution set={20,21,22,23,24,25,27,29,30,31}

Program code statements in the first execution set that are relationally connected to the correct variable PO2are then used to generate the first sensitized set. For example, program code statement23actually assigns a value to the correct variable PO2. This assignment, in turn, depends on the variable w2. Variable w2is assigned in program code statement31. This is due to the “if” statement of program code statement30, embedded in the subroutine defined by program code statement29, and which, in turn, depends on variable sel2. Variable sel2is assigned a value in program code statement21from a logical OR of two primary inputs, PI3and PI4. This yields then, in item numbers, a preliminary set for the correct variable PO2:

To generate the first sensitized set for the correct variable PO2, the preliminary set is intersected with the error set to yield: First sensitized set={21,29,30}

For every program code statement in the first sensitized set, a value of one is added to the corresponding element in the priority set, which acts as a scaling function that indicates a reduced computed probability of the related program code statement as being a source of the bug: Sensitized set:{21,29,30} Error set: {20,21,24,25,27,29,30,3b} Priority values:{0,0+1,0,0,0,0+1,0+1,0}

Program code statements21,29and30each thereby acquire a priority of one, indicating that they have a reduced computed probability that they are sources of the bug.

For the same execution cycle, a second sensitized set is also found for the error variable PO1. The first execution set is thus used, together with the error set, to obtain the second sensitized set. The procedure iterated above is used to obtain:

Analogously, for every program code statement in the second sensitized set, a value of one is added to the corresponding element in the priority set to indicate reduced computed probabilities for these program code statements as being bug sources: Sensitized set:{20,21,24,25,27,29,30} Error set:{20,21,24,25,27,29,30,3b}Priority values:{0+1,1+1,0+1,0+1,0+1,1+1,1+1,0}

This completes the analysis for the first execution cycle. At this point, the highest contender for the source of the bug is program code statement3b, with a priority value of zero. The lowest contenders are program code statements21,29and30, with priority values of 2. The other program code statements20,24,25, and27lie in-between these two extremes, with a priority value of one each.

The above procedure is repeated for execution cycle2. This requires a second execution set indicating all of the program code statements executed in the second execution cycle: Second execution set={20,21,22,23,24,25,26,29,30,31}

A third sensitized set is found, which is for the correct variable PO2in the second execution cycle. A fourth sensitized set is also found, which is for the error variable PO1in the second execution cycle. These are found to be (using item numbers): Third sensitized set={21,29,30} Fourth sensitized set={20,24,25}

It is worth noting that the fourth sensitized set is so small because, in the second execution cycle, as indicated by the second execution set, the program code statement27is not executed. The error variable PO1thus has no relational connection with the variable w2, and hence all program code statements relationally connected to the variable w2are left out of the fourth sensitized set. The third and fourth sensitized sets are used to adjust the corresponding priority values within the priority set, yielding: Error set:{20,21,24,25,27,29,30,3b} Priority values: {2,3,2,2,1,3,3,0}

The error set is then sorted based on the priority set, from most-likely error source to least-likely error source: Error set:{3b,27,20,24,25,21,29,30} Priority values: {0,1,2,2,2,3,3,3}

Line20, which is, in fact the error source, is properly identified as the program code statement having the highest computed probability of being the error source of the bug.

The above example has been presented with a very simple fragment of computer code. As such, only one correct variable, PO2, is used. However, in practice, a plurality of correct variables will be used to generate the priority values held in the priority set, and these may be selected by the user, or chosen automatically. Additionally, the user may also select a plurality of error variables. In this case, the error set would be the union of the individual error sets of each error variable. The basic method presented above would, however, remain the same. It should be obvious that the actual program code statements1are not contained within the sensitized sets or the error set. Rather, these sets hold pointers, source code line numbers, or other similar indicators, to reference the appropriate program code statements. Also, above, a constant value (namely one) is added to each priority value that corresponds to a program code statement held within a sensitized set. This is the simplest manner of performing a scaling function. Other scaling functions are also possible, and could be quite complex in nature. What is of importance, though, is that, regardless of the method used, for each program code statement in a sensitized set, the scaling function set a reduced computed probability of the program code statement being an error source.

The method of the present invention is intended to be implemented on a computer system, such as the computer system10, as a convenient feature within a program debugging tool. Please refer toFIG. 4in conjunction withFIG. 3.FIG. 4is a block diagram of the computer system10ofFIG. 3. The computer system10has an output system13, which includes the display12and may include a printer15. The computer system10also has an input system18, which includes the mouse14and keyboard16. Additionally, the computer system10comprises a processor11and memory19. The processor11executes programs in the memory19, and uses the memory19to store data.

The memory19includes program code20, an execution system30, debug information40, a user input/output (I/O) system50, and a prioritizing system60. The program code20comprises a plurality of program code statements22, as previously illustrated inFIG. 1. The execution system30is used to execute the program code20to generate the debug information40. The execution system30can be an interpreter, a combination of compiler and debugger (a so-called development system), or may simply be a compiled version of the program code20with appropriate instructions embedded therein to generate the debug information40. The debug information40comprises data about the execution of the program code20, and this data can be organized into a plurality of execution cycle blocks42. Each execution cycle block42contains all the data needed by the prioritizing system60to generate a sensitized set for a respective execution cycle of the program code20, such as lines44that indicate program code statements22that were executed in the respective execution cycle, and variable data46that holds the values of variables in the program code20at the end of the respective execution cycle. In particular, the debug information will hold information about an error execution cycle42e, in which an error variable46eobtains an error value49ethat disagrees with a desired value. With reference to the example above, the error execution cycle42ewould thus be the third execution cycle. The error variable48ewould be the variable PO1, and the error value49ewould be one, disagreeing with the desired value of zero. Execution set44econtains the program code statements22that are executed within the error execution cycle42e, and would correspond to the execution set of the above example.

The user I/O system50is used to present data to the user by way of the display12or printer15, and to obtain data from the user by way of the mouse14and keyboard16. In a development system, the user I/O system50is the heart of the system10, presenting the program code20to the user for editing and review, enabling the user to control the execution system30to trace through the program code20while viewing the contents of the processor11and memory19, permitting the user to view the contents of the debug information40, and performing a host of other tasks.

The prioritizing system60interfaces with the user I/O system50to implement the present invention method. The prioritizing system60utilizes the user I/O system50to obtain information70from the user, such as correct variables72(i.e., PO2in the example above), error variables74(i.e., PO1), the error cycle76, the number of cycles to process prior to the error cycle, and any other relevant information. In particular, the error cycle76should correspond with the error execution cycle42eif one of the error variables74is the error variable48e. With this information obtained from the user, the prioritizing system60then parses the program code20to obtain the error space63, and analyzes the debug information40with respect to the program code20and the error space63to obtain the error set62and sensitized sets69. As noted previously, the error space63contains references to all program code statements22that are relationally connected to the error variables74. The error set62comprises a plurality of target lines64with corresponding priorities66. Each target line64is in the error space63and corresponds to one of the program code statements22within the program code20. Each priority66is the computed probability that the related target line64is an error source within the program code 20. The user I/O system50then presents, on the display12(or printed out with the printer15), the error set62and related priorities64in a manner sorted according to the priorities64, with a target line64having the highest computed probability of being an error source being displayed first. As previously discussed, the sensitized sets69are used to generate the priority values66. Each set69awithin the sensitized sets69corresponds to one of the execution cycles42prior to the error execution cycle42e, and is with respect to either one of the correct variables72or one of the error variables74.

The prioritizing system60contains a function call that returns a sensitized set69agiven the three inputs noted in the above example. That is, within the prioritizing system60, a pseudo-code routine for returning a sensitized set69ahas the form: Sensitized set=GetSensitizedSet(variable, execution cycle, error set);

This pseudo-code subroutine returns a sensitized set69aas desired based upon the three input parameters: a correct variable72or error variable74, an execution cycle42, and the error set60. For example, the first sensitized set discussed in the example above would have a pseudo-code call that looks like: First sensitized set=GetSensitizedSet(PO2, first execution set, error set);

The second sensitized set discussed in the example above would have a pseudo-code call that looks like: Second sensitized set=GetSensitizedSet(PO1, first execution set, error set);

The benefit of the above is that the error set62can be found simply as a sensitized set, using the error variables74, the error cycle76, and the error space63as the three input parameters, respectively.

Although the above method and corresponding system have been presented by way of example with HDL code, it should be clear to one in the art that the present invention method is suitable for not only HDL code but any type of computer code that contains a repetitively executed loop within which a bug is known to exist.

In contrast to the prior art, the present invention identifies, and prioritizes, program code statements as being error sources within a program. These prioritized program code statements are presented to the user in order, from most-likely error source to least-likely error source. The user thus need not trace through code looking for likely sources of a bug, but instead needs only to identify a variable that is known to be incorrect, an execution cycle in which the bug occurs, and any correct variables within this buggy execution cycle. The prioritizing system according to the present invention method then performs parsing and post-process analysis of the program code to find most likely culprit program code statements and present them to the user.