CA2143145C - Determining dynamic properties of programs - Google Patents
Determining dynamic properties of programsInfo
- Publication number
- CA2143145C CA2143145C CA002143145A CA2143145A CA2143145C CA 2143145 C CA2143145 C CA 2143145C CA 002143145 A CA002143145 A CA 002143145A CA 2143145 A CA2143145 A CA 2143145A CA 2143145 C CA2143145 C CA 2143145C
- Authority
- CA
- Canada
- Prior art keywords
- program
- computer program
- source code
- execution environment
- static analysis
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
Techniques for obtaining information about dynamic properties of a program.
The techniques involve programming a programmable execution environment such as a debugger so that when the program is executed in the execution environment, side effects of the execution provide the information about the dynamic properties.
The program for the execution environment is produced by a source code analyzer which statically analyzes the source code. The source code analyzer is in turn produced by a code analyzer generator. Output from the execution environment may be provided to a graphical display system. In one use of the techniques, the code analyzer generator not only generates a source code analyzer for producing the program for the execution environment, but also a source code analyzer for producing a program which when executed by a graphical browser makes a flow graph for the program.
In this case, the graphical browser responds to the output from the execution environment by altering the appearance of the flow graph.
The techniques involve programming a programmable execution environment such as a debugger so that when the program is executed in the execution environment, side effects of the execution provide the information about the dynamic properties.
The program for the execution environment is produced by a source code analyzer which statically analyzes the source code. The source code analyzer is in turn produced by a code analyzer generator. Output from the execution environment may be provided to a graphical display system. In one use of the techniques, the code analyzer generator not only generates a source code analyzer for producing the program for the execution environment, but also a source code analyzer for producing a program which when executed by a graphical browser makes a flow graph for the program.
In this case, the graphical browser responds to the output from the execution environment by altering the appearance of the flow graph.
Description
2I4314a DETERMINITIG DYNAMIC PROPERTIES OF PROGRAMS
Background of the Invention Field of the Invention This invention relates to software testing and verification in general and more particularly to determining dynamic properties of programs.
Description of the Prior Art Introduction When developing large F~rograms, it is often important to have knowledge about dynamic properties: properties that can be determined only by running the program.
Often, the dynamic properties involve information that is not visible during the normal operation of the program. Examples of such dynamic properties with respect to a program P
and a set of inputs 1 for the progr;~,m are:
1. When run with inputs I, does P execute all its functions ?
Background of the Invention Field of the Invention This invention relates to software testing and verification in general and more particularly to determining dynamic properties of programs.
Description of the Prior Art Introduction When developing large F~rograms, it is often important to have knowledge about dynamic properties: properties that can be determined only by running the program.
Often, the dynamic properties involve information that is not visible during the normal operation of the program. Examples of such dynamic properties with respect to a program P
and a set of inputs 1 for the progr;~,m are:
1. When run with inputs I, does P execute all its functions ?
2. When run with inputs l, does P execute all its IF-statements in both directions ?
3. When run with inputs I, does it ever happen that the pointer variable aPerson, which is known be of type struct person * ever point to an object which is not of type struct person ?
In order to make the alr~ove information and other information like it externally visible, the program needs to be instrnmented in some way so that it produces output containing the desired information. Instrumentation can be done during the process of building the program, that is the pr~~cess of compiling the source code to produce object code and linking the object code to produce executable code and can be done on the executable code itself.
One way of instrumenting a program during program build is to simply add code for the instrumentation to the source code and then compile the source code to produce the object code. The object code o:f course contains code corresponding to the instrumentation code which was added to the .source code. Another way of doing it is to compile the source code using a special compiler which adds the necessary instrumentation to the object code. The first technique, adding instrumentation code to the source code, is very general; the kinds of instrumentation which c~~,n be added are limited only by the ingenuity of the programmer.
The disadvantage, of course, is that adding the instrumentation has meant changing the source code; thus, the source code being investigated is no longer the original source code.
Using specialized compilers to produce the transformed code does not require chang ing the source code, but is considerably less general; only those kinds of instrumentation can be added which are provided by the particular special compiler. Other types of in strumentation require other special compilers or even modification of one of the existing special compilers. Examples of such special compilers are lcc or cc -p, available on com-puter systems operating under the well-known uNIx operating system (uNlx is a registered trademark of XOPEN). ~~11 of the techniques for instrumenting a program when it is built suffer from the difficulty that the building process can be very complex, and it is often difficult to ensure that the instrumented version of the program built by the build process is functionally equivalent to the version which the build process builds for customers.
There further exist tools for instrumenting the object code of a program after the program has been built. An example of such a tools is PURIFY, sold by Pure Software, Inc., 1309 S. Mary Ave., Sunnyvale, CA., which exploits special patterns of machine code sequences and compiler code generation techniques to identify locations in the binary that are relevant to the property being investigated. The disadvantages of tools like PURIFY are that each tool permits investigation of a small fixed set of properties and that there is no portability, since a version of the tool is required for each different class of processor.
FIG. 1 provides a conceptual overview of systems of the type just described.
Under normal circumstances, a system 102 of one or more programs runs with inputs 101 in an execution environment 104. Under these conditions, an internal property such as "does this system execute all functions on inputs 101" cannot be determined. To determine the internal property, we build a trcansformed version of the system 105, which has been instru-mented to generate side effects when something happens during an execution of system 102 which is relevant to the ~3esired property.
For instance, if one wants to find out if system 102 executes all of its functions when executed with inputs 101, one can instrument system 102 by inserting a print statement at the beginning of the source code for each function called by system 102. The instrumen-tation transforms system 102 into system 105. Now this transformed system 105 is run on inputs 101. Each time transformed system 105 executes a function, it executes the print statement which was inserted at the beginning of the function. The execution of the print statement is a side effect 106, and by looking at the output from the print statements, the programmer can determine which of the print statements were executed and can use that information to determine which functions were executed.
An example of how source code may be modified to determine test coverage for a given set of test inputs is shown in FIG. 4. In this case, the goal is to determine if the test has caused every if-statement to exercise both its true branch and its false branch. The original source code 401 with an if-statement (true and false branches on lines 2 and 5 respectively) is modified by inserting print statements (402) at lines l.i and 4.i; when this modified code is executed, messages about branch executions are output to a log file and test coverage can be det<~rmined by looking at the messages in the log file.
As indicated above, all of the existing techniques for determining dynamic properties of systems have disadvantages. Instrumentation of source code requires modification of the code under test, and the i.nstrumented source code is thus not exactly equivalent to the non instrumented source cod<~. Special-purpose compilers can produce instrumentation only for certain dynamic properties. Further, any instrumentation process which requires rebuilding the system being tested becomes less desirable when the program building environment becomes complex. Tools 'which instrument already-built executable binaries are as inflexible as the special-purpose compilers, and have the further disadvantage of lack of portability.
What is needed, and what is provided by the techniques disclosed herein is a way of investigating the dynamic properties of programs which does not involve modification of the source code of the program being tested, which can easily be adapted to test any class of dynamic property, and which is highly portable.
Summary of the Invention The techniques of the invention solve the problems of the prior art by programming a pro-grammable execution environment to provide the desired information about the dynamic properties. The unmodified code for the program under investigation is then executed in the programmed execution Environment, and the execution environment responds to the execution of the program under investigation by outputting information about the dynamic properties of interest. In a preferred embodiment, the program for the execution environment is produced by statically analyzing the source code for the program under investigation. One way of doing the static analysis is to provide a specification of the analysis to a tool which generates code analyzers. The tool then produces the code analyzer, which is in turn applied to the source code for the program under investigation to produce the program for the execution environment. Source code analyzers may be produced equally easily for many dynamic properties, and execution environments are available which have been ported to many different machines. The techniques of the invention thus not only avoid modification of the source code being tested, but may also be used to produce apparatus for testing an infinite variety of dynamic properties. Finally, the techniques may be used with any programmable execution environment and are as portable as the execution environments themselves.
According to om; aspect of the invention there is provided an apparatus for determining information concerning the dynamic properties of a computer program, comprising: means for performing a static analysis of said computer program;
means for producing an analysis program in response to said static analysis; and means for executing said computer program under the control of said analysis program to provide information concerning said dynamic properties of said computer program.
According to another aspect of the invention there is provided a method for determining information concerning the dynamic properties of a computer program, without modifying the source code of the computer program, comprising the steps of:
performing a static analysis of said computer program; producing an analysis program in response to said static analysis; and executing said computer program under the control of said analysis program to determine information concerning said dynamic properties of said computer program, said dynamic properties being properties that can only be determined when said computer program is executed.
According to yet a~zother aspect of the invention there is provided an apparatus which is implemented using a computer system, the apparatus being used to obtain first information about a dynamic property of a first executable program accessible to the computer system and the apparatus comprising: static analysis means for performing a static analysis of second information about the first program and producing a second program therefrom, the second information being accessible to the computer system and the static analysis means executing in the computer system; and programmable execution environment means for executing the first program under control of a second program, the programmable execution environment means executing in the computer system and the second program causing the programmable execution Environment means to output the first information while executing the first program.
The foregoing and other objects and advantages of the invention will be immediately apparent to those of ordinary skill in the art upon perusal of the following Drawing and Detailed Description.
Brief Description of the Drawing FIG. 1 is a conceptual di~~gram of prior-art techniques for determining dynamic properties of programs;
FIG. 2 is a conceptual di~~gram of the techniques of the present invention for determining dynamic properties of programs;
FIG. 3 is a diagram of an embodiment in which the execution environment is a debugger;
FIG. 4 shows a prior-art technique for instrumenting source code to determine the branch 4a coverage property of a program;
FIG. 5 shows how the technique of the present invention may be employed to modify the execution environment s~o that it may be used to determine the branch coverage property of a program;
FIG. 6 shows how a st~~,tic analysis of the program's parse tree is employed to generate code for the modification of the execution environment;
FIG. 7 shows how output from the execution environment may be applied to a graph browsing program to produce a dynamic graphical representation of the results of a test of a program; and FIG. 8 shows a portion of the GENOA specification used to generate a static analyzer.
Reference numbers in the Drawing have two parts: the two least-significant digits are the number of an item i.n a figure; the remaining digits are the number of the figure in which the item first appesars. Thus, an item with the reference number 201 first appears in FIG. 2.
Detailed Description of a Preferred Embodiment The following Detailed Description will first present a general overview of the concept of the invention and will thereupon describe a preferred embodiment using a programmable debugger as the programmable execution environment. The Detailed Description will also disclose how static source code analyzers may be used to produce code for the programmable debugger and how such static source code analyzers may be produced using a system for generating code analyzers. Finally, an embodiment will be disclosed in which the side effects from the programmable debugger drive a graphical display of a flow graph for the program being tested.
Overview of the Invention: FIG. 2 The techniques employe~3 in the invention to investigate dynamic properties of programs are shown in overview in FIG. 2. System 202 is made up of one or more programs which are executed in a programmz~ble execution environment 203. One example of such an execution environment is a programmable debugger. We are interested in some dynamic property 207 which system 202 exhibits when executed with inputs 201. Instead of transforming the system, as in FIG. l., we leave system 202 unchanged, so that system 202 is identical with system 204, which is shown separately in FIG. 2 just for convenience, and instead transform execution environment 203 into another execution environment 205.
How the transformation is done depends both on the system being analyzed (202 - 204) and the dynamic property 207. Transformed execution environment 205 interrupts the execution of the programs of system 204 (- 202) at points that are determined by the property and the system itself, and generates side effects 206. These side effects, like the side effects 106 generated in FIG. 1, can. be used to investigate property 207.
Example Embodiment: FIG. 3 FIG. 3 shows an example embodiment of how a dynamic property may be investigated by modifying an executiion environment as described in the previous section.
In FIG. 3, execution environment 2 03 is a debugger 306. Debuggers are tools used by programmers for finding bugs in programs. When a program is being debugged, it is executed in the debugger. The debugger permits the programmer to precisely control the execution of the program. A fundamental capability of debuggers is setting breakpoints. A
breakpoint is a location in the program at which control passes from the program to the debugger when the program is executed in the debugger. Many debuggers are programmable, that is, the programmer can provide the debugger with a list of instructions which specify not only the locations of the bre~~,kpoints, but also actions which the debugger is to take when it encounters the break point. Actions may include halting execution until the person using the debugger restarts it or printing out the contents of machine registers and/or memory locations.
Debuggers of the type used in the present invention work with the executable binaries for a program. The programmer using the debugger specifies a location for a break point relative to the source code for the program. The debugger then finds the corresponding location in the executat~le binary code and replaces the instruction at that point in the executable binary with an illegal instruction. The debugger retains the replaced instruction and the action which th<~ debugger is to take at the breakpoint.
When the program :is executed and the point at which the break point was set is reached, the hardware responds to the illegal instruction with an illegal instruction event.
The debugger responds vto the illegal instruction event by executing the action which the programmer specified for the break point. When that has been done, the debugger replaces the illegal instruction with the retained actual instruction, executes that instruction, and passes control back to the program, which continues executing until it reaches the next breakpoint.
In the example impl~smentation of the invention, such a debugger 306 is used to de termine a specific property 308 of system 302 when run with inputs 303. First, a static analyzer 304 is created for the specific property. Static analyzer 304 is applied to source code 301 for the system and generates a sequence of commands 305 for the debugger 306.
Now, the system 302 can be loaded into the debugger 306; the debugger then configures itself by executing commands 305 generated by static analyzer 304 and finally executes system 302 using inputs 303. As configured by generated commands 305, debugger interrupts the execution of system 302 at specified points and creates side effects 307 (for example, writing information about the state of the program at the time of the interruption of execution into a log file). The side effects can then be analyzed for information about dynamic property 307.
A specific example of this approach in use is shown in FIG. 5. Here the application is software testing; it is desired to determine whether a set of tests is complete, that is, whether the tests have executed both the true and false branches of every if-statement. For example, in source code 501, there is an if-statement on line 1, with true-and false-branches beginning at lines 2 and 5 respectively, and the tests must execute both branches. In the preferred embodiment, ~~tatic analyzer 304 is made using GENOA, a tool for generating source code analyzers. GENOA is described in Devanbu P., GENOA- A language and front-end independent source code analyzer generator, Proceedings, Twelfth International Conference on Softv~are Engineering, May 1992. Static analyzer 304 produced by GENOA
works on a parse tree representation of source code 501 for the program.
A parse tree is a set of labelled nodes with labelled edges connecting them.
The nodes represent different parts of the parse tree. The labels on the nodes represent the type of syntactic structure represented by the node. The entire source file containing the program being analyzed is represented by the node labelled File. Somewhere below this node in the tree is the node labelled If corresponding to the If-statement 601. This portion of the parse tree appears at reference number 602 in FIG. 6. There are two edges going out of this node, lablelled they and else (shown in typewriter font) which correspond to the then- and else-parts of the If-statement 601. Each of these edges connect the If node (line 1 in 601) to Block nodes representing the blocks beginning at lines 2 and 5 in 601.
Static analyzer 304 :produced by GENOA) traverses the parse tree looking for nodes representing If-statements. When the analyzer finds a nodes for an If-statement, it de-termines from the parse tree what the starting locations in the source code are for the true- and false- branches, and generates debugger commands 502 (FIG. 5) specifying those locations and actions to be taken when they are reached. When the commands are pro-vided to debugger 306 a.nd the system 302 built from the source 501 is executed by the debugger as configured by the commands, the debugger performs the action specified for the breakpoint at each breakpoint reached by the execution. If the actions specified for all of the breakpoints have taken place, the set of tests is complete with regard to the branches of the if staternents. It should be noted here that the debugger instructions need not be produced from source 501, but can be produced as well from any available source of information about the: program being tested.
As is apparent from i;he foregoing discussion, the technique requires no modification of the source code. The modifications of the executable binary produced by the debugger are temporary and do not involve the addition of instructions to the executable binary. When the debugger is one which is available on many platforms, one gains the convenience of binary instrumentation without sacrificing portability. An example of such a debugger is gdb, described in Stallm;~,n, R., and Pesch, R., Debugging with GDB, available by Internet file transfer from prep . a~it . edu).
In order to make the alr~ove information and other information like it externally visible, the program needs to be instrnmented in some way so that it produces output containing the desired information. Instrumentation can be done during the process of building the program, that is the pr~~cess of compiling the source code to produce object code and linking the object code to produce executable code and can be done on the executable code itself.
One way of instrumenting a program during program build is to simply add code for the instrumentation to the source code and then compile the source code to produce the object code. The object code o:f course contains code corresponding to the instrumentation code which was added to the .source code. Another way of doing it is to compile the source code using a special compiler which adds the necessary instrumentation to the object code. The first technique, adding instrumentation code to the source code, is very general; the kinds of instrumentation which c~~,n be added are limited only by the ingenuity of the programmer.
The disadvantage, of course, is that adding the instrumentation has meant changing the source code; thus, the source code being investigated is no longer the original source code.
Using specialized compilers to produce the transformed code does not require chang ing the source code, but is considerably less general; only those kinds of instrumentation can be added which are provided by the particular special compiler. Other types of in strumentation require other special compilers or even modification of one of the existing special compilers. Examples of such special compilers are lcc or cc -p, available on com-puter systems operating under the well-known uNIx operating system (uNlx is a registered trademark of XOPEN). ~~11 of the techniques for instrumenting a program when it is built suffer from the difficulty that the building process can be very complex, and it is often difficult to ensure that the instrumented version of the program built by the build process is functionally equivalent to the version which the build process builds for customers.
There further exist tools for instrumenting the object code of a program after the program has been built. An example of such a tools is PURIFY, sold by Pure Software, Inc., 1309 S. Mary Ave., Sunnyvale, CA., which exploits special patterns of machine code sequences and compiler code generation techniques to identify locations in the binary that are relevant to the property being investigated. The disadvantages of tools like PURIFY are that each tool permits investigation of a small fixed set of properties and that there is no portability, since a version of the tool is required for each different class of processor.
FIG. 1 provides a conceptual overview of systems of the type just described.
Under normal circumstances, a system 102 of one or more programs runs with inputs 101 in an execution environment 104. Under these conditions, an internal property such as "does this system execute all functions on inputs 101" cannot be determined. To determine the internal property, we build a trcansformed version of the system 105, which has been instru-mented to generate side effects when something happens during an execution of system 102 which is relevant to the ~3esired property.
For instance, if one wants to find out if system 102 executes all of its functions when executed with inputs 101, one can instrument system 102 by inserting a print statement at the beginning of the source code for each function called by system 102. The instrumen-tation transforms system 102 into system 105. Now this transformed system 105 is run on inputs 101. Each time transformed system 105 executes a function, it executes the print statement which was inserted at the beginning of the function. The execution of the print statement is a side effect 106, and by looking at the output from the print statements, the programmer can determine which of the print statements were executed and can use that information to determine which functions were executed.
An example of how source code may be modified to determine test coverage for a given set of test inputs is shown in FIG. 4. In this case, the goal is to determine if the test has caused every if-statement to exercise both its true branch and its false branch. The original source code 401 with an if-statement (true and false branches on lines 2 and 5 respectively) is modified by inserting print statements (402) at lines l.i and 4.i; when this modified code is executed, messages about branch executions are output to a log file and test coverage can be det<~rmined by looking at the messages in the log file.
As indicated above, all of the existing techniques for determining dynamic properties of systems have disadvantages. Instrumentation of source code requires modification of the code under test, and the i.nstrumented source code is thus not exactly equivalent to the non instrumented source cod<~. Special-purpose compilers can produce instrumentation only for certain dynamic properties. Further, any instrumentation process which requires rebuilding the system being tested becomes less desirable when the program building environment becomes complex. Tools 'which instrument already-built executable binaries are as inflexible as the special-purpose compilers, and have the further disadvantage of lack of portability.
What is needed, and what is provided by the techniques disclosed herein is a way of investigating the dynamic properties of programs which does not involve modification of the source code of the program being tested, which can easily be adapted to test any class of dynamic property, and which is highly portable.
Summary of the Invention The techniques of the invention solve the problems of the prior art by programming a pro-grammable execution environment to provide the desired information about the dynamic properties. The unmodified code for the program under investigation is then executed in the programmed execution Environment, and the execution environment responds to the execution of the program under investigation by outputting information about the dynamic properties of interest. In a preferred embodiment, the program for the execution environment is produced by statically analyzing the source code for the program under investigation. One way of doing the static analysis is to provide a specification of the analysis to a tool which generates code analyzers. The tool then produces the code analyzer, which is in turn applied to the source code for the program under investigation to produce the program for the execution environment. Source code analyzers may be produced equally easily for many dynamic properties, and execution environments are available which have been ported to many different machines. The techniques of the invention thus not only avoid modification of the source code being tested, but may also be used to produce apparatus for testing an infinite variety of dynamic properties. Finally, the techniques may be used with any programmable execution environment and are as portable as the execution environments themselves.
According to om; aspect of the invention there is provided an apparatus for determining information concerning the dynamic properties of a computer program, comprising: means for performing a static analysis of said computer program;
means for producing an analysis program in response to said static analysis; and means for executing said computer program under the control of said analysis program to provide information concerning said dynamic properties of said computer program.
According to another aspect of the invention there is provided a method for determining information concerning the dynamic properties of a computer program, without modifying the source code of the computer program, comprising the steps of:
performing a static analysis of said computer program; producing an analysis program in response to said static analysis; and executing said computer program under the control of said analysis program to determine information concerning said dynamic properties of said computer program, said dynamic properties being properties that can only be determined when said computer program is executed.
According to yet a~zother aspect of the invention there is provided an apparatus which is implemented using a computer system, the apparatus being used to obtain first information about a dynamic property of a first executable program accessible to the computer system and the apparatus comprising: static analysis means for performing a static analysis of second information about the first program and producing a second program therefrom, the second information being accessible to the computer system and the static analysis means executing in the computer system; and programmable execution environment means for executing the first program under control of a second program, the programmable execution environment means executing in the computer system and the second program causing the programmable execution Environment means to output the first information while executing the first program.
The foregoing and other objects and advantages of the invention will be immediately apparent to those of ordinary skill in the art upon perusal of the following Drawing and Detailed Description.
Brief Description of the Drawing FIG. 1 is a conceptual di~~gram of prior-art techniques for determining dynamic properties of programs;
FIG. 2 is a conceptual di~~gram of the techniques of the present invention for determining dynamic properties of programs;
FIG. 3 is a diagram of an embodiment in which the execution environment is a debugger;
FIG. 4 shows a prior-art technique for instrumenting source code to determine the branch 4a coverage property of a program;
FIG. 5 shows how the technique of the present invention may be employed to modify the execution environment s~o that it may be used to determine the branch coverage property of a program;
FIG. 6 shows how a st~~,tic analysis of the program's parse tree is employed to generate code for the modification of the execution environment;
FIG. 7 shows how output from the execution environment may be applied to a graph browsing program to produce a dynamic graphical representation of the results of a test of a program; and FIG. 8 shows a portion of the GENOA specification used to generate a static analyzer.
Reference numbers in the Drawing have two parts: the two least-significant digits are the number of an item i.n a figure; the remaining digits are the number of the figure in which the item first appesars. Thus, an item with the reference number 201 first appears in FIG. 2.
Detailed Description of a Preferred Embodiment The following Detailed Description will first present a general overview of the concept of the invention and will thereupon describe a preferred embodiment using a programmable debugger as the programmable execution environment. The Detailed Description will also disclose how static source code analyzers may be used to produce code for the programmable debugger and how such static source code analyzers may be produced using a system for generating code analyzers. Finally, an embodiment will be disclosed in which the side effects from the programmable debugger drive a graphical display of a flow graph for the program being tested.
Overview of the Invention: FIG. 2 The techniques employe~3 in the invention to investigate dynamic properties of programs are shown in overview in FIG. 2. System 202 is made up of one or more programs which are executed in a programmz~ble execution environment 203. One example of such an execution environment is a programmable debugger. We are interested in some dynamic property 207 which system 202 exhibits when executed with inputs 201. Instead of transforming the system, as in FIG. l., we leave system 202 unchanged, so that system 202 is identical with system 204, which is shown separately in FIG. 2 just for convenience, and instead transform execution environment 203 into another execution environment 205.
How the transformation is done depends both on the system being analyzed (202 - 204) and the dynamic property 207. Transformed execution environment 205 interrupts the execution of the programs of system 204 (- 202) at points that are determined by the property and the system itself, and generates side effects 206. These side effects, like the side effects 106 generated in FIG. 1, can. be used to investigate property 207.
Example Embodiment: FIG. 3 FIG. 3 shows an example embodiment of how a dynamic property may be investigated by modifying an executiion environment as described in the previous section.
In FIG. 3, execution environment 2 03 is a debugger 306. Debuggers are tools used by programmers for finding bugs in programs. When a program is being debugged, it is executed in the debugger. The debugger permits the programmer to precisely control the execution of the program. A fundamental capability of debuggers is setting breakpoints. A
breakpoint is a location in the program at which control passes from the program to the debugger when the program is executed in the debugger. Many debuggers are programmable, that is, the programmer can provide the debugger with a list of instructions which specify not only the locations of the bre~~,kpoints, but also actions which the debugger is to take when it encounters the break point. Actions may include halting execution until the person using the debugger restarts it or printing out the contents of machine registers and/or memory locations.
Debuggers of the type used in the present invention work with the executable binaries for a program. The programmer using the debugger specifies a location for a break point relative to the source code for the program. The debugger then finds the corresponding location in the executat~le binary code and replaces the instruction at that point in the executable binary with an illegal instruction. The debugger retains the replaced instruction and the action which th<~ debugger is to take at the breakpoint.
When the program :is executed and the point at which the break point was set is reached, the hardware responds to the illegal instruction with an illegal instruction event.
The debugger responds vto the illegal instruction event by executing the action which the programmer specified for the break point. When that has been done, the debugger replaces the illegal instruction with the retained actual instruction, executes that instruction, and passes control back to the program, which continues executing until it reaches the next breakpoint.
In the example impl~smentation of the invention, such a debugger 306 is used to de termine a specific property 308 of system 302 when run with inputs 303. First, a static analyzer 304 is created for the specific property. Static analyzer 304 is applied to source code 301 for the system and generates a sequence of commands 305 for the debugger 306.
Now, the system 302 can be loaded into the debugger 306; the debugger then configures itself by executing commands 305 generated by static analyzer 304 and finally executes system 302 using inputs 303. As configured by generated commands 305, debugger interrupts the execution of system 302 at specified points and creates side effects 307 (for example, writing information about the state of the program at the time of the interruption of execution into a log file). The side effects can then be analyzed for information about dynamic property 307.
A specific example of this approach in use is shown in FIG. 5. Here the application is software testing; it is desired to determine whether a set of tests is complete, that is, whether the tests have executed both the true and false branches of every if-statement. For example, in source code 501, there is an if-statement on line 1, with true-and false-branches beginning at lines 2 and 5 respectively, and the tests must execute both branches. In the preferred embodiment, ~~tatic analyzer 304 is made using GENOA, a tool for generating source code analyzers. GENOA is described in Devanbu P., GENOA- A language and front-end independent source code analyzer generator, Proceedings, Twelfth International Conference on Softv~are Engineering, May 1992. Static analyzer 304 produced by GENOA
works on a parse tree representation of source code 501 for the program.
A parse tree is a set of labelled nodes with labelled edges connecting them.
The nodes represent different parts of the parse tree. The labels on the nodes represent the type of syntactic structure represented by the node. The entire source file containing the program being analyzed is represented by the node labelled File. Somewhere below this node in the tree is the node labelled If corresponding to the If-statement 601. This portion of the parse tree appears at reference number 602 in FIG. 6. There are two edges going out of this node, lablelled they and else (shown in typewriter font) which correspond to the then- and else-parts of the If-statement 601. Each of these edges connect the If node (line 1 in 601) to Block nodes representing the blocks beginning at lines 2 and 5 in 601.
Static analyzer 304 :produced by GENOA) traverses the parse tree looking for nodes representing If-statements. When the analyzer finds a nodes for an If-statement, it de-termines from the parse tree what the starting locations in the source code are for the true- and false- branches, and generates debugger commands 502 (FIG. 5) specifying those locations and actions to be taken when they are reached. When the commands are pro-vided to debugger 306 a.nd the system 302 built from the source 501 is executed by the debugger as configured by the commands, the debugger performs the action specified for the breakpoint at each breakpoint reached by the execution. If the actions specified for all of the breakpoints have taken place, the set of tests is complete with regard to the branches of the if staternents. It should be noted here that the debugger instructions need not be produced from source 501, but can be produced as well from any available source of information about the: program being tested.
As is apparent from i;he foregoing discussion, the technique requires no modification of the source code. The modifications of the executable binary produced by the debugger are temporary and do not involve the addition of instructions to the executable binary. When the debugger is one which is available on many platforms, one gains the convenience of binary instrumentation without sacrificing portability. An example of such a debugger is gdb, described in Stallm;~,n, R., and Pesch, R., Debugging with GDB, available by Internet file transfer from prep . a~it . edu).
214~14~
Coupling the Dynamic Property Analyzer to a Graphical Dis-play: FIG. ?
The side effects 307 produced by debugger 306 may of course be provided to any kind of device which produce; output which is useful for analyzing the dynamic property. For example, in FIG. 7, the' side effects 307 are used to animate a flow graph 705. Flow graph 705 is produced i:n this example using another static analyzer made with GENOA.
Flow graph 705 is provided to graphical browser 706 for visual display. Then, we analyze the source code to produce commands 703 for a debugger 704 as described above.
The commands set break points at beginnings of blocks etc; each time a break point is activated, the debugger responds as specified by the commands. In this case, the commands specify that an inter-process message 708 specifying a modification in the visual display of the flow graph be sent from the F~rocess in which debugger 704 is executing to the process in which graphical browser 706 is executing. In response to the message, graphical browser 706 modifies the visual display. This technique can be used for visual display of test coverage information or simply as an aid to program comprehension and debugging.
Using GENOA to make a static analyzer: FIG. 8 A portion of a specification used with GENOA to produce a static analyzer 304 are shown in FIG. 8. The static analyzer which GENOA produces from the specification performs a search of the entire program for blocks and switch statements. The search is specified by the square brackets a.t line 801 and the end of line 807. What is being searched for is specified at line 802 (for the blocks) and line 804 (for the switch statements). Line 803 specifies that break points are to be set at the beginning of the block and that debugger commands are to be generated for each break point which instruct the debugger to delete the breakpoint and continue. For switch statements, breakpoints are set at each case of the switch (line 807) and the same debugger commands are to be generated.
Since each breakpoint is deleted wh<>.n activated, the breakpoints remaining after a test run indicate the parts of the code that h~~ve not been executed. The programmable debugger employed in the preferred embodiment indicates to the user which break points have not been executed, ~14314~
and thus indicates which parts of the code have not been executed. For more details on GENOA and the language it uses to specify static code analyzers, see Devanbu P., GENOA-A language and front-end independent source code analyzer generator, Proceedings, Twelfth International Conferences on Software Engineering, May 1992).
As is apparent from ~F'IG. 8, the use of a static source code analyzer generator such as GENOA greatly simplifies the implementation of static analyzers 304. When a tool such as GENOA is used together ~;vith a programmable and portable debugger such as gdb, one can easily implement devices to determine a wide range of dynamic properties on a wide range of hardware.
Conclusion The foregoing Detailed Description has disclosed to those skilled in the art the best mode presently known to the inventor of practicing his techniques for determining dynamic prop-erties of a program without modifying the source code. Instead, the techniques produce a modified execution environment. When the program is executed in the modified execution environment, side effect~~ are produced which permit study of a given dynamic property.
Particular advantages of these techniques arise from the following features:
~ the execution environment is easily programmable;
~ the program for the execution environment may be produced by applying a static source code analyzer to the source code of the program being studied;
~ the execution environment, operates in many different machine environments;
and ~ the static source code analyzer may be produced using a source code analyzer gener-ator.
In the preferred embodiment, the execution environment is a debugger; however, the prin ciples of the invention may be employed with any programmable execution environment.
Moreover, while the preferred embodiment employs a static analysis of the source code to produce the instructions for the programmable execution environment, any kind of analysis which produced such instructions could be used instead. Finally, it is particularly advan-tageous to use a system such as GENOA to produce the static analyzer, but the analyzer could be produced in any way, including by hand. Having understood the principles of the techniques disclosed herein, those skilled in the art will be able to produce systems S which employ the principles of the invention, but differ in every other respect from the embodiments disclosed herein.
That being the case, the Detailed Description is to be understood as being in all re-spects illustrative and e~:emplary, but not restrictive, and the scope of the invention is not to be defined by the Detailed Description, but rather by the claims as interpreted with the full breadth permitted by the law.
What is claimed i:c:
Coupling the Dynamic Property Analyzer to a Graphical Dis-play: FIG. ?
The side effects 307 produced by debugger 306 may of course be provided to any kind of device which produce; output which is useful for analyzing the dynamic property. For example, in FIG. 7, the' side effects 307 are used to animate a flow graph 705. Flow graph 705 is produced i:n this example using another static analyzer made with GENOA.
Flow graph 705 is provided to graphical browser 706 for visual display. Then, we analyze the source code to produce commands 703 for a debugger 704 as described above.
The commands set break points at beginnings of blocks etc; each time a break point is activated, the debugger responds as specified by the commands. In this case, the commands specify that an inter-process message 708 specifying a modification in the visual display of the flow graph be sent from the F~rocess in which debugger 704 is executing to the process in which graphical browser 706 is executing. In response to the message, graphical browser 706 modifies the visual display. This technique can be used for visual display of test coverage information or simply as an aid to program comprehension and debugging.
Using GENOA to make a static analyzer: FIG. 8 A portion of a specification used with GENOA to produce a static analyzer 304 are shown in FIG. 8. The static analyzer which GENOA produces from the specification performs a search of the entire program for blocks and switch statements. The search is specified by the square brackets a.t line 801 and the end of line 807. What is being searched for is specified at line 802 (for the blocks) and line 804 (for the switch statements). Line 803 specifies that break points are to be set at the beginning of the block and that debugger commands are to be generated for each break point which instruct the debugger to delete the breakpoint and continue. For switch statements, breakpoints are set at each case of the switch (line 807) and the same debugger commands are to be generated.
Since each breakpoint is deleted wh<>.n activated, the breakpoints remaining after a test run indicate the parts of the code that h~~ve not been executed. The programmable debugger employed in the preferred embodiment indicates to the user which break points have not been executed, ~14314~
and thus indicates which parts of the code have not been executed. For more details on GENOA and the language it uses to specify static code analyzers, see Devanbu P., GENOA-A language and front-end independent source code analyzer generator, Proceedings, Twelfth International Conferences on Software Engineering, May 1992).
As is apparent from ~F'IG. 8, the use of a static source code analyzer generator such as GENOA greatly simplifies the implementation of static analyzers 304. When a tool such as GENOA is used together ~;vith a programmable and portable debugger such as gdb, one can easily implement devices to determine a wide range of dynamic properties on a wide range of hardware.
Conclusion The foregoing Detailed Description has disclosed to those skilled in the art the best mode presently known to the inventor of practicing his techniques for determining dynamic prop-erties of a program without modifying the source code. Instead, the techniques produce a modified execution environment. When the program is executed in the modified execution environment, side effect~~ are produced which permit study of a given dynamic property.
Particular advantages of these techniques arise from the following features:
~ the execution environment is easily programmable;
~ the program for the execution environment may be produced by applying a static source code analyzer to the source code of the program being studied;
~ the execution environment, operates in many different machine environments;
and ~ the static source code analyzer may be produced using a source code analyzer gener-ator.
In the preferred embodiment, the execution environment is a debugger; however, the prin ciples of the invention may be employed with any programmable execution environment.
Moreover, while the preferred embodiment employs a static analysis of the source code to produce the instructions for the programmable execution environment, any kind of analysis which produced such instructions could be used instead. Finally, it is particularly advan-tageous to use a system such as GENOA to produce the static analyzer, but the analyzer could be produced in any way, including by hand. Having understood the principles of the techniques disclosed herein, those skilled in the art will be able to produce systems S which employ the principles of the invention, but differ in every other respect from the embodiments disclosed herein.
That being the case, the Detailed Description is to be understood as being in all re-spects illustrative and e~:emplary, but not restrictive, and the scope of the invention is not to be defined by the Detailed Description, but rather by the claims as interpreted with the full breadth permitted by the law.
What is claimed i:c:
Claims (28)
1. An apparatus for determining information concerning the dynamic properties of a computer program, comprising:
means for performing a static analysis of said computer program; means for producing an analysis program in response to said static analysis; and means for executing said computer program under the control of said analysis program to provide information concerning said dynamic properties of said computer program.
means for performing a static analysis of said computer program; means for producing an analysis program in response to said static analysis; and means for executing said computer program under the control of said analysis program to provide information concerning said dynamic properties of said computer program.
2. The apparatus according to claim 1, wherein said means for performing a static analysis includes:
means for generating a code analyzer; and means for providing a specification of said static analysis.
means for generating a code analyzer; and means for providing a specification of said static analysis.
3. The apparatus according to claim 2, wherein said means for performing a static analysis includes:
means for receiving the source code of said computer program.
means for receiving the source code of said computer program.
4. The apparatus according to claim 3, wherein said means for producing an analysis program includes:
means for applying said generated code analyzer to said source code.
means for applying said generated code analyzer to said source code.
5. The apparatus according to claim 1, wherein said means for executing includes a programmable execution environment.
6. The apparatus according to claim 5, wherein said programmable execution environment includes a programmable debugger.
7. The apparatus according to claim 1, further comprising:
display means for displaying said information concerning said dynamic properties of said computer program.
display means for displaying said information concerning said dynamic properties of said computer program.
8. The apparatus according to claim 7, wherein said means for performing a static analysis includes:
means for generating a code analyzer; and means for providing a specification of said static analysis.
means for generating a code analyzer; and means for providing a specification of said static analysis.
9. The apparatus according to claim 8, wherein said means for performing a static analysis includes:
means for receiving the source code of said computer program.
means for receiving the source code of said computer program.
10. The apparatus according to claim 9, wherein said means for producing an analysis program include:
means for applying said generated code analyzer to said source code.
means for applying said generated code analyzer to said source code.
11. The apparatus according to claim 8, wherein said means for executing includes a programmable execution environment.
12. The apparatus according to claim 11, wherein said programmable execution environment includes a programmable debugger.
13. A method for determining information concerning the dynamic properties of a computer program, without modifying the source code of the computer program, comprising the steps of:
performing a static analysis of said computer program;
producing an analysis program in response to said static analysis; and executing said computer program under the control of said analysis program to determine information concerning said dynamic properties of said computer program, said dynamic properties being properties that can only be determined when said computer program is executed.
performing a static analysis of said computer program;
producing an analysis program in response to said static analysis; and executing said computer program under the control of said analysis program to determine information concerning said dynamic properties of said computer program, said dynamic properties being properties that can only be determined when said computer program is executed.
14. The method according to claim 13, wherein said step of performing a static analysis includes the steps of:
generating a code analyzer; and providing a specification of said static analysis.
generating a code analyzer; and providing a specification of said static analysis.
15. The method according to claim 14, wherein said step of performing a static analysis includes the step of:
receiving the source code of said computer program.
receiving the source code of said computer program.
16. The method according to claim 15, wherein said step of producing an analysis program includes the step of:
applying said generated code analyzer to said source code of said computer program.
applying said generated code analyzer to said source code of said computer program.
17. The method according to claim 13, wherein said step of executing said computer program includes the step of using a programmable execution environment.
18. The method according to claim 17, wherein said step of using a programmable execution environment includes the step of providing a programmable debugger.
19. The method according to claim 13, also including the step of:
displaying said information concerning said dynamic properties of said computer program.
displaying said information concerning said dynamic properties of said computer program.
20. A method for determining information concerning the dynamic properties of a computer program without modifying the source code of the computer program, comprising the steps of:
performing a static analysis of said computer program by generating a code analyzer, providing a specification of said static analysis and receiving the source code of said computer program;
producing an analysis program in response to said static analysis by applying said generated code analyzer to said source code;
executing said computer program under the control of said analysis program to determine information concerning said dynamic properties of said computer program by using a programmable execution environment; and displaying said information concerning said dynamic properties of said computer program.
performing a static analysis of said computer program by generating a code analyzer, providing a specification of said static analysis and receiving the source code of said computer program;
producing an analysis program in response to said static analysis by applying said generated code analyzer to said source code;
executing said computer program under the control of said analysis program to determine information concerning said dynamic properties of said computer program by using a programmable execution environment; and displaying said information concerning said dynamic properties of said computer program.
21. An apparatus for determining information concerning properties of a computer program that can only be determined while the computer program is being executed, comprising:
means for performing a static analysis of said computer program;
means for producing an analysis program in response to said static analysis;
and means for executing said computer program under the control of said analysis program to provide information concerning said properties of said computer program.
means for performing a static analysis of said computer program;
means for producing an analysis program in response to said static analysis;
and means for executing said computer program under the control of said analysis program to provide information concerning said properties of said computer program.
22. The apparatus according to claim 21, wherein said means for performing a static analysis includes:
means for generating a code analyzer; and means for providing a specification of said static analysis.
means for generating a code analyzer; and means for providing a specification of said static analysis.
23. The apparatus according to claim 22, wherein said means for performing a static analysis includes:
means for receiving the source code of said computer program.
means for receiving the source code of said computer program.
24. The apparatus according to claim 23, wherein said means for producing an analysis program includes:
means for applying said generated code analyzer to said source code without modifying said source code.
means for applying said generated code analyzer to said source code without modifying said source code.
25. The apparatus according to claim 21, wherein said means for executing includes a programmable execution environment.
26. The apparatus according to claim 25, wherein said programmable execution environment includes a programmable debugger.
27. The apparatus according to claim 21, further comprising:
display means for displaying said information concerning said properties of said computer program.
display means for displaying said information concerning said properties of said computer program.
28. An apparatus which is implemented using a computer system, the apparatus being used to obtain first information about a dynamic property of a first executable program accessible to the computer system and the apparatus comprising:
static analysis means for performing a static analysis of second information about the first program and producing a second program therefrom, the second information being accessible to the computer system and the static analysis means executing in the computer system; and programmable execution environment means for executing the first program under control of a second program, the programmable execution environment means executing in the computer system axed the second program causing the programmable execution environment means to output the first information while executing the first program.
static analysis means for performing a static analysis of second information about the first program and producing a second program therefrom, the second information being accessible to the computer system and the static analysis means executing in the computer system; and programmable execution environment means for executing the first program under control of a second program, the programmable execution environment means executing in the computer system axed the second program causing the programmable execution environment means to output the first information while executing the first program.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US22904394A | 1994-04-18 | 1994-04-18 | |
| US229,043 | 1994-04-18 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2143145A1 CA2143145A1 (en) | 1995-10-19 |
| CA2143145C true CA2143145C (en) | 1999-12-28 |
Family
ID=22859617
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002143145A Expired - Fee Related CA2143145C (en) | 1994-04-18 | 1995-02-22 | Determining dynamic properties of programs |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5832271A (en) |
| EP (1) | EP0678810A1 (en) |
| JP (1) | JPH07295859A (en) |
| CA (1) | CA2143145C (en) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5909577A (en) * | 1994-04-18 | 1999-06-01 | Lucent Technologies Inc. | Determining dynamic properties of programs |
| US6098092A (en) * | 1996-11-08 | 2000-08-01 | Silicon Graphics, Inc. | Server to dynamically generate graphics for the world wide web |
| US5953534A (en) * | 1997-12-23 | 1999-09-14 | University Of Washington | Environment manipulation for executing modified executable and dynamically-loaded library files |
| US6216237B1 (en) * | 1998-06-19 | 2001-04-10 | Lucent Technologies Inc. | Distributed indirect software instrumentation |
| US6279149B1 (en) * | 1998-09-24 | 2001-08-21 | International Business Machines Corporation | Aggregate structure identification and its application to program analysis |
| US6959431B1 (en) * | 1999-05-13 | 2005-10-25 | Compuware Corporation | System and method to measure and report on effectiveness of software program testing |
| US6427232B1 (en) | 1999-06-10 | 2002-07-30 | International Business Machines Corporation | Functional debugger for debugging software programs |
| US6775827B1 (en) * | 1999-09-20 | 2004-08-10 | Harkins Audit Software, Inc. | Real-time program audit software |
| US7240336B1 (en) | 2000-07-25 | 2007-07-03 | Sci Systems, Inc. | Interpretive simulation of software download process |
| US7055146B1 (en) | 2001-03-08 | 2006-05-30 | Microsoft Corporation | Method and system for dynamically inserting modifications for identified programs |
| US7191436B1 (en) | 2001-03-08 | 2007-03-13 | Microsoft Corporation | Computer system utility facilitating dynamically providing program modifications for identified programs |
| US20050081104A1 (en) * | 2003-09-25 | 2005-04-14 | Borislav Nikolik | Test diversity software testing method and apparatus |
| US7657869B2 (en) * | 2004-02-05 | 2010-02-02 | Microsoft Corporation | Integration of external tools into an existing design environment |
| JP4776235B2 (en) * | 2005-01-07 | 2011-09-21 | ソニー株式会社 | Information processing apparatus and method, and program |
| US7549144B2 (en) * | 2005-02-22 | 2009-06-16 | Microsoft Corporation | Custom API modeling for source code static analysis simulator |
| US7779399B2 (en) * | 2005-05-16 | 2010-08-17 | Armorize Technologies, Inc. | System and method for securing web application code and verifying correctness of software |
| US8212805B1 (en) | 2007-01-05 | 2012-07-03 | Kenneth Banschick | System and method for parametric display of modular aesthetic designs |
| JP2008257390A (en) * | 2007-04-03 | 2008-10-23 | Toshiba Information Systems (Japan) Corp | Unit and program for program inspection |
| EP2223213B1 (en) * | 2007-11-20 | 2019-09-11 | Synopsys, Inc. | Multi language software code analysis |
| WO2010060283A1 (en) * | 2008-11-28 | 2010-06-03 | 上海芯豪微电子有限公司 | Data processing method and device |
| EP2261802A1 (en) * | 2009-06-10 | 2010-12-15 | ITI Scotland Limited | Automated debugging system and method |
| US10157049B2 (en) * | 2011-10-26 | 2018-12-18 | International Business Machines Corporation | Static analysis with input reduction |
| US8918881B2 (en) | 2012-02-24 | 2014-12-23 | Appthority, Inc. | Off-device anti-malware protection for mobile devices |
| US8713684B2 (en) | 2012-02-24 | 2014-04-29 | Appthority, Inc. | Quantifying the risks of applications for mobile devices |
| US8819772B2 (en) | 2012-06-25 | 2014-08-26 | Appthority, Inc. | In-line filtering of insecure or unwanted mobile device software components or communications |
| US9552285B2 (en) | 2013-05-02 | 2017-01-24 | Microsoft Technology Licensing, Llc | Micro-execution for software testing |
| JP6088445B2 (en) * | 2014-01-07 | 2017-03-01 | 日本電信電話株式会社 | Software scale arithmetic device and program |
| US10379825B2 (en) | 2017-05-22 | 2019-08-13 | Ab Initio Technology Llc | Automated dependency analyzer for heterogeneously programmed data processing system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4080650A (en) * | 1976-07-28 | 1978-03-21 | Bell Telephone Laboratories, Incorporated | Facilitating return from an on-line debugging program to a target program breakpoint |
| US4914568A (en) * | 1986-10-24 | 1990-04-03 | National Instruments, Inc. | Graphical system for modelling a process and associated method |
| US4819234A (en) * | 1987-05-01 | 1989-04-04 | Prime Computer, Inc. | Operating system debugger |
| US5038348A (en) * | 1988-07-01 | 1991-08-06 | Sharp Kabushiki Kaisha | Apparatus for debugging a data flow program |
| US5313616A (en) * | 1990-09-18 | 1994-05-17 | 88Open Consortium, Ltd. | Method for analyzing calls of application program by inserting monitoring routines into the executable version and redirecting calls to the monitoring routines |
-
1995
- 1995-02-22 CA CA002143145A patent/CA2143145C/en not_active Expired - Fee Related
- 1995-04-04 EP EP95302242A patent/EP0678810A1/en not_active Ceased
- 1995-04-18 JP JP7092036A patent/JPH07295859A/en active Pending
-
1996
- 1996-07-08 US US08/677,000 patent/US5832271A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2143145A1 (en) | 1995-10-19 |
| JPH07295859A (en) | 1995-11-10 |
| EP0678810A1 (en) | 1995-10-25 |
| US5832271A (en) | 1998-11-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2143145C (en) | Determining dynamic properties of programs | |
| US5909577A (en) | Determining dynamic properties of programs | |
| US6493868B1 (en) | Integrated development tool | |
| CA2332650C (en) | Software analysis system having an apparatus for selectively collecting analysis data from a target system executing software instrumented with tag statements and method for use thereof | |
| US6003143A (en) | Tool and method for diagnosing and correcting errors in a computer program | |
| US6430741B1 (en) | System and method for data coverage analysis of a computer program | |
| US7478366B2 (en) | Debugger and method for debugging computer programs across multiple programming languages | |
| US7266809B2 (en) | Software debugger and software development support system for microcomputer operable to execute conditional execution instruction | |
| US6493834B1 (en) | Apparatus and method for dynamically defining exception handlers in a debugger | |
| EP0539120B1 (en) | Source code analyzer | |
| JP2000122886A (en) | Program production system of semiconductor testing device | |
| Xie et al. | Automatic extraction of abstract-object-state machines from unit-test executions | |
| US6993749B2 (en) | Conditional debug monitors | |
| Usui et al. | Bugdel: An aspect-oriented debugging system | |
| Spinellis | Trace: A tool for logging operating system call transactions | |
| Lyle et al. | Using the unravel program slicing tool to evaluate high integrity software | |
| Ekman et al. | Dynamic patching of embedded software | |
| Cunha et al. | A distributed debugging tool for a parallel software engineering environment | |
| Penev et al. | Visual differential debugging in the domain-specific visual programming languages | |
| Henriques et al. | ALMA versus DDD | |
| Cruz et al. | ALMA versus DDD | |
| Cao | Aiding automated testing generation process by visualizing dynamic symbolic execution | |
| da Cruz et al. | ALMA versus DDD. | |
| CN113836046A (en) | Debugging method and system for application program of virtual machine on MCU (microprogrammed control Unit) | |
| Frakes | A Software Engineering Methodology for the Unix/C Environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |