JP4966904B2 - Program diagnostic apparatus, program diagnostic method and program thereof - Google Patents

Description

  The present invention relates to a program diagnosis apparatus, a program diagnosis method, and a program for detecting a race condition of access to a common resource of a program executed in parallel from program source code.

  Conventionally, a technology called exclusive control has been used in computer systems. Here, the deposit management system when the exclusive control is not performed and the deposit management system when the exclusive control is performed will be described using specific examples. First, in a deposit management system that does not perform exclusive control, the deposit program deposits 30,000 yen into a deposit balance of 50,000 yen (shared variable) and registers 80,000 yen as the deposit amount. Explained as an example. Here, when the deposit program and the withdrawal program are executed at the same timing, the withdrawal program reads the deposit balance of 50,000 yen while the deposit program is processing, There is a possibility of calculating 40,000 yen, which is a withdrawal process of 000 yen, and registering information on the amount of 40,000 yen in the deposit amount after the completion of the deposit program. In such a case, the deposit balance is recorded as 40,000 yen that does not reflect the processing of the deposit program, and 50,000 yen (deposit balance) +30,000 (deposit amount) -10,000 (withdrawal amount) ) = It is not an accurate amount as calculated at 70,000 yen. In order to avoid such a program race condition, it is necessary to perform exclusive control. In other words, while the deposit program is being executed for the shared variable, the shared variable is locked, and the processing of the withdrawal program for the shared variable is locked (so as not to be executed). It is necessary to control to be 70,000 yen.

Similarly, a race condition occurs in processing of a web server connected to the Internet. The figure shown in FIG. 19 is a figure which shows the competition state in a web server. As shown in the figure, in the state where the user A who uses the client terminal A and the user B who uses the client terminal B are accessing the web server at the same time, the program that controls the processing from the client A and the client B When the program for controlling the above process conflicts, there is a possibility that the web page to be transmitted to the client terminal B is transmitted to the client terminal A. Patent Document 1 discloses a technique for performing a program diagnosis as to whether these race conditions occur in a web server program.
JP 2007-257397 A

  Here, in the technique of the above-described Patent Document 1, a shared variable reading process and a shared variable writing process are detected in a program that performs parallel / parallel operations, and the value of the shared variable in the shared variable reading process is detected. Compare the values of the shared variables immediately before the shared variable write process. If the values do not match in the comparison, it is detected that there is a race condition, and the source code with the assert statement added at the location in the program where the race condition occurs is output. However, in the technique of Patent Document 1, although it is possible to detect whether or not a race condition has occurred by dynamic analysis of a virtual machine, if the program needs to be corrected so as not to cause a race condition, the description position of the program Cannot be specified. Further, since the assert statement is added to the source code of the program, the program itself is modified. Furthermore, the technique of Patent Document 1 has a problem that if a race condition does not occur during dynamic analysis of a virtual machine, it cannot be detected.

  Therefore, the present invention provides a program diagnostic apparatus that enables a program producer to easily detect and correct an instruction code that causes a race condition without altering the description of the source code of the program and with high accuracy. It is an object to provide a program diagnosis method and a program thereof.

In order to achieve the above object, the present invention provides a program diagnostic apparatus for detecting a race condition for access to a common resource of a program executed in parallel, the program input receiving means for receiving the program input, Intermediate code generating means for generating intermediate code ; instruction code temporary execution means for temporarily executing the instruction code described in the intermediate code; based on the result of the temporary execution, the temporarily executed instruction code; and History that creates a history table that associates identification information of an object variable that an instruction code reads and writes, a description position in the intermediate code of the instruction code, and an identifier that indicates that parallel execution of other instruction codes is permitted and table creation means, instruction codes on the basis of the intermediate code, to read and write object variable Among them, the program diagnostic apparatus characterized by comprising: a command code detecting means for detecting an instruction code that is described in the history table associated with the identifier indicating the permission of the parallel execution of other instruction code, the is there.

The present invention, in the above-described program analysis device, a row in the Help program source code instructions code the detection is written, the detection instruction code position display means for displaying on the display screen of the program source code, the It is characterized by providing.

According to the present invention, in the above program analysis apparatus, the detected instruction in association with the code on the basis of the description position of the intermediate code recorded in the history table, the instruction code in the Help program source code is written And an instruction code position specifying means for specifying the line.

Further, the present invention is the above-described program diagnosis apparatus, wherein the history table creation means includes an instruction code for controlling the access to the common resource in the history table and an instruction code corresponding to the instruction code. An identifier indicating that parallel execution of other instruction codes is not permitted for instruction codes recorded between the description positions in the intermediate code of the instruction codes for releasing the control that cannot access the common resource It is characterized by recording in association with correspondence .

The present invention is a program analysis method in the program diagnosing apparatus for detecting an access conflict state to a common resource of a program to be executed in parallel, receiving the input of said program, and generates an intermediate code of said program, said intermediate An instruction code described in the code is provisionally executed, and based on the result of the provisional execution, the provisionally executed instruction code, identification information of an object variable that the instruction code reads and writes, and the intermediate of the instruction code Create a history table that associates the description position in the code with an identifier indicating that parallel execution of other instruction codes is permitted, and among other instruction codes that read and write object variables based on the intermediate code associated with the identifier indicating the permission of the parallel execution of the instruction code to the history table Is a program analysis method characterized by detecting an instruction code that is mounting.

Further, the present invention provides a computer of a program diagnostic apparatus for detecting a race condition for access to a common resource of a program executed in parallel, program input receiving means for receiving the program input, and intermediate code generation for generating the intermediate code of the program Means for provisionally executing an instruction code described in the intermediate code, based on the result of the provisional execution, identification of the provisionally executed instruction code and an object variable to be read and written by the instruction code A history table creating means for creating a history table associating information, a description position of the instruction code in the intermediate code, and an identifier indicating that parallel execution of another instruction code is permitted , based on the intermediate code Of the instruction codes that read and write object variables, other instruction codes Is a program for functioning as an instruction code detecting means for detecting an instruction code that is described in the history table associated with the identifier indicating the permission of the parallel execution.

  According to the present invention, an intermediate code is generated from a source code of a program, and an instruction code indicating memory reference / write is detected from the intermediate code. When it is determined in the temporary execution of the instruction code that the variable to be operated is an instruction code executed in the unlocked state, the position of the source code in which the instruction code is described is displayed on the screen. Yes. Therefore, the user can detect and correct which source code location description should be changed so as not to cause a race condition without altering the source code description. In addition, since all instruction codes indicating memory reference / write can be detected, the position of the source code corresponding to the instruction code that causes a race condition can be detected with high accuracy.

Hereinafter, a program diagnostic apparatus according to an embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing the configuration of the program diagnosis apparatus according to the embodiment.
In this figure, reference numeral 1 denotes a program diagnostic apparatus. The program diagnosis apparatus 1 includes a Web application analysis unit 11, a diagnosis execution unit 12, a race condition condition determination unit 13, a display unit 14, an instruction code storage unit 15, an operand stack 16, and a memory monitoring history DB (database) 17. ing.

  The program diagnostic apparatus 1 detects an access contention state to a common resource of programs executed in parallel from the program source code, and first receives an input of the program. Next, an intermediate code of the program is generated. Based on the intermediate code, an instruction code associated with an identifier that permits parallel execution of other instruction codes is detected among instruction codes for reading and writing object variables. Furthermore, a process of displaying a line in the program source code in which the detected instruction code is described on the display screen of the program source code is performed. As a result, the screen is output to the monitor so that the program producer can easily detect and correct the instruction code that causes a race condition without altering the description of the source code of the program. Yes.

FIG. 2 is a diagram showing an outline of processing of the program diagnostic apparatus.
As shown in this figure, the program diagnostic apparatus 1 according to the present embodiment compiles a Java (registered trademark) language program source code into a Java (registered trademark) language intermediate code (byte code), and uses the intermediate code. Based on the information recorded in the database, a diagnosis of whether or not a vulnerability of the source code, that is, an access race state to a common resource of a program executed in parallel does not occur. Then, processing for displaying a warning marker or the like in a description line corresponding to an instruction code that may cause a race condition in the program source code of Java (registered trademark) language is performed.

  Here, the diagnosis program in this embodiment is a filter program, a listener program, a Java (registered trademark) servlet program, or a Java (registered trademark) that starts processing in response to reception of request information from the client in the web application server. ) Server page program. These programs are programs that operate when receiving request information from a client terminal operated by a user. In an electronic payment site or the like, it is necessary to strictly check the reduction of the occurrence of a competitive state in the web application server, and the program diagnosis according to the present embodiment is particularly to be performed. The diagnosis method by the program diagnosis apparatus 1 of the present embodiment operates on other servers other than the filter program, listener program, Java (registered trademark) servlet program, and Java (registered trademark) server page program of the web application server. You may make it use for the diagnosis of the race condition of the program to perform. In this embodiment, the program source code in the Java (registered trademark) language is compiled into intermediate code (byte code) in the Java (registered trademark) language. This is because the intermediate code is compared with the source code. This is because the granularity of the processing information appears finely and attribute information such as variables and object states is included. By using these attribute information, a highly accurate diagnosis is executed.

FIG. 3 is a diagram showing an outline of a contention state of access to common resources of programs executed in parallel.
As shown in this figure, when two threads are executed on the web application server, a certain common resource (variable, object, etc.) can accept access from both threads (Unlock state) In such a case, an access contention state may occur, and the data value of the common resource may be different from the desired value. Therefore, when one of the threads is accessing a common resource, depending on the instruction code, the other one or more threads may not be able to access the common resource (lock ( Lock) state). If a description is found in the program that performs access processing to a common resource that may cause a race condition, the location is a description in the program that may cause a race condition. Can be determined.

FIG. 4 is a first diagram showing a processing flow of the program diagnosis apparatus.
Next, an overview of the processing flow of the program diagnostic apparatus 1 will be described. First, the web application analysis unit 11 reads all “user request reception process start methods” from all source files constituting the web application server (step S1). This “user request reception process start method” accepts request information from a user terminal such as a filter program, a listener program, a Java (registered trademark) servlet program, a Java (registered trademark) server page program of the web application server. Is included in the class that starts the process. Here, the method is a program in which a command of an operation instruction for each object possessed by each object is described in object-oriented programming.

  Then, the web application analysis unit 11 generates an “execution module group” from one “user request reception process start method” (step S2). Then, the web application analysis unit 11 determines whether the generated source code including the “execution module group” has been compiled (step S3), and if not compiled, compiles the source code to generate an intermediate code. (Step S31). Then, the web application analysis unit 11 stores the instruction code described in the intermediate code in the instruction code storage unit 15 in the order of processing executed in response to request information from the user terminal (step S4).

  Next, the diagnosis execution unit 12 reads the instruction code from the instruction code storage unit 15, performs emulation execution (pseudo execution) on the operand stack 16, and operates the shared memory used by the web application (memory operation) The byte code position (instruction code) (a value indicating the number of bytes with the head of the method in the middle (byte) code of the instruction code as 0) is read from the instruction code storage unit 15 (step S5). Then, the diagnosis execution unit 12 writes the history such as the byte code position of the memory operation instruction code and the state of the shared memory changed by the memory operation instruction code in the memory monitoring history table of the memory monitoring history DB 17 (step S6). Next, the race condition condition determination unit 13 reads the memory monitoring history table and records the race condition (associated with an identifier that permits parallel execution of other instruction codes among instruction codes for reading and writing object variables). Read the byte code position of the memory operation instruction code corresponding to the variable for which the condition code is true (step S7). Then, the position information of the execution module group is calculated from the byte code position of the memory operation instruction code read by the race condition condition determination unit 13 and notified to the display unit 14 (step S8). The display unit 14 outputs the position information of the execution module group to an external display device such as a monitor (step S9).

Next, the details of the processing in steps S1 to S9 will be described.
FIG. 5 is a second diagram showing a processing flow of the program diagnosis apparatus.
As shown in the figure, in step S1, the web application analysis unit 11 first reads a directory / path in which source files constituting the web application are stored (step S11). Then, the web application analysis unit 11 reads the web application deployment descriptor (deployment descriptor) stored under the directory / path, and from the descriptor, the web application server filter program, listener program, Java (registered trademark). ) The names of the servlet program and the Java (registered trademark) server page program are read (step S12). Further, the web application analysis unit 11 obtains a superclass of the class having the name specified in step S12 from the target source file (namely, the source file constituting the web application) for which the name is specified. The method defined in “Request reception process start method list” is stored in the memory as “User request reception process start method” (step S13).

FIG. 6 is a diagram showing a list of methods for starting processing when a user request is received.
The “user request reception process start method list” is stored in advance in a storage unit or the like, and one or more methods are described for each class as shown in FIG.

FIG. 7 is a third diagram showing a processing flow of the program diagnosis apparatus.
Next, in step S2, first, the web application analysis unit 11 reads one method from the list of “user request reception process start method” stored in the memory in step S13 (step S21). Then, the web application analysis unit 11 reads all instruction codes executed in the method and generates a list of instruction codes (step S22). Next, the web application analysis unit 11 sets a list of instruction codes as “execution module group (a set of instruction codes in a method executed in a series of processes starting from“ user request reception process start method ”)”. It is additionally recorded temporarily in the data table in the memory (step S23). Then, the web application analysis unit 11 determines whether the instruction code list in the execution module group is empty in the data table temporarily recorded in the memory (step S24). Otherwise, one instruction code is read from the instruction code list (step S25). Then, it is determined whether the instruction code is an instruction code for executing a method call (step S26). If the instruction code does not execute the method call, the process returns to step S25 to read the next instruction code. If it is an instruction code for executing a method call, the process after step S22 is recursively executed for the called method (other method) (step S27).

  Then, as shown in steps S3, S31, and S4, the web application analysis unit 11 determines whether the generated source code including the “execution module group” has been compiled. Compile source code to generate intermediate code. Then, the web application analysis unit 11 stores the instruction code described in the intermediate code in the instruction code storage unit 15 in the order of processing to be executed in response to request information from the user terminal.

FIG. 8 is a diagram illustrating an example of data <intermediate (byte) code> stored in the instruction code storage unit.
As shown in this figure, the instruction code stored by the web application analysis unit 11 is described in the intermediate (byte) code table of the instruction code storage unit 15. Each instruction code is recorded in 1-byte units, and associated with each instruction code is the byte code position indicating the order of the 1-byte unit (how many bytes with the beginning of the method in the middle (byte) code of the instruction code set to 0) A value indicating whether or not the eye is recorded). It is assumed that the bytecode position of the instruction code in the instruction code storage unit 15 and the description position (line number) in the source code of the web application are described in the intermediate (byte) code.

FIG. 9 is a fourth diagram showing a processing flow of the program diagnostic apparatus.
FIG. 10 is a fifth diagram showing a processing flow of the program diagnostic apparatus.
Next, in step S5 described above, first, when the diagnosis execution unit 12 is instructed to emulate (pseudo execution) the instruction code on the operand stack 16, the data recorded in the instruction code storage unit 15 is recorded. One instruction code is read from the table. Then, the diagnosis execution unit 12 determines whether or not the read instruction code is a code (getstatic or putstatic?) That refers to or writes to the class variable (object variable) (step S51). If Yes, it is determined that the instruction code is for operating the shared memory, and if No, it is determined that the instruction code is not for operating the shared memory. The diagnosis execution unit 12 determines whether the read instruction code is a code (getfield or putfield?) For referring to or writing to the instance variable (object variable) (step S52). Further, the diagnosis execution unit 12 determines whether the instance variable (object variable) to be referred to or written to the read instruction code is an instance of the web application (step S53). This is determined by the determination information represented by the first argument of the instruction code. If Yes in step S53, it is determined that the instruction code is for operating (referencing / writing) the shared memory. Further, when it is determined No in step S52 or No in step S53, it is determined that the instruction code is not for operating the shared memory.

  Next, the diagnosis execution unit 12 sequentially reads instruction codes determined to be instruction codes for operating the shared memory (step S501). Then, the diagnosis execution unit 12 reads the byte code position of the read instruction code from the instruction code storage unit 15 (step S502). Then, the byte code position is output (step S503). The instruction code determined to be an instruction code for operating the shared memory and its byte code position are temporarily stored in a memory or the like.

FIG. 11 is a sixth diagram illustrating a processing flow of the program diagnostic apparatus.
Next, the diagnosis execution unit 12 acquires an instruction code that is determined to be an instruction code for operating the shared memory, which is temporarily stored in the memory (step S61). Then, it is determined whether the instruction code is an instruction code indicating a memory reference (getstatic / putstatic / getfield / putfield) (step S62). In the case of Yes, if the information indicating whether or not the instruction code for performing the operation (referencing / writing) of the shared memory is True by the processing in steps S51 to S53, the instruction code and the byte code position thereof are determined. Are associated and written in the memory monitoring history table in the memory monitoring history DB (step S63). Then, it is determined whether or not the instruction code is locked by a lock command (monitorenter) that controls to prevent access to the common resource when the instruction code is executed (step S64). If it is locked, the memory acquired by the variable / unlock target acquisition process described below is associated with the information indicating that the variable is “locked state” to monitor the memory. Write to the history table (step S64).

  Further, it is determined whether or not the instruction code has been unlocked by a lock release command (monitorexit) indicating release of control that cannot access the common resource when the instruction code is executed (step S65). If it can be determined that the lock has been released by the lock release command, the variable acquired by the lock / unlock target acquisition process described below is associated with the information indicating that the variable is “unlocked” Is written in the memory monitoring history table (step S66). Then, it is determined whether or not provisional execution has been completed for all instruction codes in the execution module group (step S67). If it is determined that provisional execution has been completed for all instruction codes, the process ends.

FIG. 12 is a seventh diagram showing the processing flow of the program diagnostic apparatus.
FIG. 12 is a diagram showing the above-described lock / unlock target variable acquisition process. In this process, if the command is a lock command (monitorenter) or an unlock command (monitorexit), the instruction code is read (step S601). Then, the variable name is read from the operand stack 16 (step S602), and the variable name is output (step S603).

FIG. 13 is a diagram illustrating an example of a memory monitoring history table.
As shown in this figure, the memory monitoring history table includes an instruction code determined to be an instruction code for operating a shared memory, its byte code position, and a variable (object) that is a common resource operated by the instruction code. ) And information on a state indicating whether the variable is in a locked state or an unlocked state when the instruction code is executed.

FIG. 14 is a diagram showing an outline of the memory monitoring history table and the competition condition determination process.
As shown in FIG. 14, in this embodiment, instruction codes indicating memory references are putfield (a value is stored in an instance variable), getfield (a value is acquired from an instance variable), putstatic (a value is stored in a class variable) , Getstatic (obtains a value from a class variable), and information indicating that these instruction codes and variables (objects) that are common resources at the time of execution of the instruction codes are in an “unlocked state” Only when the instruction code is associated with the memory monitoring history table, it is determined that the instruction code may cause a race condition. Note that monitorenter (monitor start) and monitorexit (monitor end) are obtained by converting the description of “synchronized qualifier” into byte code in the source code described in the Java (registered trademark) language.

  All instruction codes recorded in the instruction code storage unit 15 at the byte code position between the monitorenter and the monitorexit instruction code are always locked to the common resource when the instruction code is executed. Therefore, in the memory monitoring history table, all the status information indicating the “locked status” is registered for the statuses of the variables operated by the instruction code between the monitorenter and the monitorexit. If there are multiple combinations of monitorenter and monitorexit, check whether all combinations of monitorenter and monitorexit appear according to the number of monitorenter described in the memory monitoring history table and the number of monitorexit described in the memory monitoring history table. After determining that all the states of the variables operated by the instruction codes between the combinations are in the “locked state” and determining that the combination of the monitorenter and the monitorexit has ended, it is in the “unlocked state”. The information shown is registered.

FIG. 15 is a diagram showing an outline of status acquisition by instruction code temporary execution on the operand stack.
As shown in this figure, first, Java (registered trademark) source code is converted into byte code. In addition, Lock or Unlock information is not statically described on the bytecode. However, when executing each instruction code in this byte code, the instruction code in the byte code corresponding to the shynchronized identifier in the source code becomes a monitorenger, and it is determined that the variable (object) state is locked by this instruction code. is doing.

FIG. 16 is an eighth diagram showing the processing flow of the program diagnostic apparatus.
Next, in step S7 described above, first, the race condition condition determination unit 13 reads a record of one instruction code from the memory monitoring history table stored in the memory monitoring history DB 17 (step S701). Information indicating that the instruction code is one of the getcode, putstatic, getfield, and putfield instruction codes indicating the memory reference, and that the variable to be operated at the time of executing the instruction code is in the unlocked state (Unlock ) And whether it is recorded in the record (step S702). In the case of Yes, it is determined that there is a possibility of a race condition and it is dangerous, and the byte code position recorded in association with the instruction code is read from the memory monitoring history table and stored in the memory or the like. Temporary recording is performed (step S703). Then, it is determined whether or not processing has been performed for all instruction code records recorded in the memory monitoring history table (step S704). If processing has not ended, the processing of steps S701 to S704 is repeated.

FIG. 17 is a ninth diagram illustrating the processing flow of the program diagnostic apparatus.
Next, in step S8 described above, first, the race condition condition determination unit 13 is an instruction code indicating a memory reference, which is temporarily recorded in a memory or the like in step S703, and the variable to be operated is in an unlocked state. The byte code position of the instruction code indicating the presence is read (step S81). Then, it corresponds to a bytecode position in a source file (a source file of any one of a filter program, a listener program, a Java (registered trademark) servlet program, and a Java (registered trademark) server page program) constituting a processing target web application. The description position (line number) in the source code is read (step S82). For example, as described above, the byte code position of the instruction code in the instruction code storage unit 15 and the description position (line number) in the source code of the web application are stored in the intermediate (byte) code. Byte) code should be read. Then, the source code position is output to the display unit 14 (step S83). Then, in the process of step S9, the line in the program source code in which the instruction code that the display unit 14 has detected that there is a possibility of a race condition is displayed on the external display device such as a monitor is displayed as the program. Display on the source code display screen and output to the external display device.

FIG. 18 shows an example of a display screen.
As shown in FIG. 18, a warning marker is displayed in the source code on the display screen. This warning marker indicates that the description of the program in the line to which the marker is attached may cause a race condition. By describing the synchronized qualifier on this line, the user avoids the occurrence of contention due to the description of the location where the warning marker is attached. Then, the diagnosis is performed again by the program diagnosis apparatus 1, and the display screen from which the warning marker is removed is output. Further, on the display screen, as shown in the lower left child screen of FIG. 18, a list screen showing the number of lines of the source code and the occurrence probability of the race condition may be displayed as the detection result.

  As described above, the embodiments of the present invention have been described. According to the above-described processing, an intermediate code is generated from a Java (registered trademark) language source code, and an instruction code indicating memory reference / write is detected from the intermediate code. To do. When it is determined in the temporary execution of the instruction code that the variable to be operated is an instruction code executed in the unlocked state, the position of the source code in which the instruction code is described is displayed on the screen. Yes. Therefore, the user can detect and correct which source code location description should be changed so as not to cause a race condition without altering the source code description. Further, since all instruction codes indicating memory reference / write can be detected, the position of the source code corresponding to the instruction code causing the race condition can be detected with high accuracy.

  The above-described program diagnosis apparatus has a computer system inside. Each process described above is stored in a computer-readable recording medium in the form of a program, and the above process is performed by the computer reading and executing the program. Here, the computer-readable recording medium means a magnetic disk, a magneto-optical disk, a CD-ROM, a DVD-ROM, a semiconductor memory, or the like. Alternatively, the computer program may be distributed to the computer via a communication line, and the computer that has received the distribution may execute the program.

  The program may be for realizing a part of the functions described above. Furthermore, what can implement | achieve the function mentioned above in combination with the program already recorded on the computer system, and what is called a difference file (difference program) may be sufficient.

It is a block diagram which shows the structure of a program diagnostic apparatus. It is a figure which shows the process outline | summary of a program diagnostic apparatus. It is a figure which shows the outline | summary of the access competition state to the common resource of the program performed in parallel. It is a 1st figure which shows the processing flow of a program diagnostic apparatus. It is a 2nd figure which shows the processing flow of a program diagnostic apparatus. It is a figure which shows the process start method list at the time of user request reception. It is a 3rd figure which shows the processing flow of a program diagnostic apparatus. It is a figure which shows the example of data <intermediate (byte) code> stored in an instruction code memory | storage part. It is a 4th figure which shows the processing flow of a program diagnostic apparatus. It is a 5th figure which shows the processing flow of a program diagnostic apparatus. It is a 6th figure which shows the processing flow of a program diagnostic apparatus. It is a 7th figure which shows the processing flow of a program diagnostic apparatus. It is a figure which shows the example of a memory monitoring log | history table. It is a figure which shows the outline | summary of a memory monitoring history table and the determination process of a competition condition. It is a figure which shows the outline | summary of the state acquisition by the instruction code temporary execution on an operand stack. It is an 8th figure which shows the processing flow of a program diagnostic apparatus. It is a 9th figure which shows the processing flow of a program diagnostic apparatus. It is a figure which shows the example of a display screen. It is a figure which shows the competition state in a web server.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Program diagnostic apparatus 11 ... Web application analysis part 12 ... Diagnosis execution part 13 ... Competition condition condition determination part 14 ... Display part 15 ... Instruction code memory | storage part 16 ... Operand Stack 17 ... Memory monitoring history DB

Claims (6)

A program diagnostic device for detecting a race condition for access to a common resource of a program executed in parallel,
Program input receiving means for receiving input of the program;
Intermediate code generating means for generating intermediate code of the program;
An instruction code provisional execution means for provisionally executing the instruction code described in the intermediate code;
Based on the result of the provisional execution, the provisionally executed instruction code, the identification information of the object variable that the instruction code reads and writes, the description position of the instruction code in the intermediate code, and the parallel execution of other instruction codes A history table creating means for creating a history table in association with an identifier indicating that
An instruction for detecting an instruction code described in the history table in association with an identifier indicating that parallel execution of other instruction codes is permitted among instruction codes for reading and writing object variables based on the intermediate code Code detection means;
A program diagnostic apparatus comprising: The lines in Help program source code instructions code the detection is written, the detection instruction code position display means for displaying on the display screen of the program source code,
The program diagnostic apparatus according to claim 1, further comprising: Based on the described position of the intermediate code recorded in the history table in association with the instruction code the detected, and the instruction code position specifying means the instruction code to identify the row in the Help program source code is written,
The program diagnostic apparatus according to claim 1 , further comprising: In the history table, the history table creating means includes an instruction code for controlling the access to the common resource, and an instruction code corresponding to the instruction code, the control not being able to access the common resource. The instruction code recorded between the description positions in the intermediate code of the instruction code to be canceled is recorded in association with an identifier indicating that parallel execution of other instruction codes is not permitted.
  The program diagnostic apparatus according to any one of claims 1 to 3, wherein A program diagnostic method in a program diagnostic apparatus for detecting a race condition for access to a common resource of programs executed in parallel,
Receiving input of the program,
Generate intermediate code of the program,
Temporarily executing the instruction code described in the intermediate code;
Based on the result of the provisional execution, the provisionally executed instruction code, the identification information of the object variable that the instruction code reads and writes, the description position of the instruction code in the intermediate code, and the parallel execution of other instruction codes Create a history table that associates identifiers indicating that
Detecting an instruction code described in the history table in association with an identifier indicating that parallel execution of other instruction codes is permitted among instruction codes for reading and writing object variables based on the intermediate code. A program diagnosis method characterized by the above. A computer of a program diagnostic apparatus for detecting a race condition for access to a common resource of programs executed in parallel,
Program input receiving means for receiving input of the program;
Intermediate code generating means for generating an intermediate code of the program;
Temporary instruction code execution means for temporarily executing the instruction code described in the intermediate code;
Based on the result of the provisional execution, the provisionally executed instruction code, the identification information of the object variable that the instruction code reads and writes, the description position of the instruction code in the intermediate code, and the parallel execution of other instruction codes A history table creating means for creating a history table associating an identifier indicating that permission is allowed,
An instruction for detecting an instruction code described in the history table in association with an identifier indicating that parallel execution of other instruction codes is permitted among instruction codes for reading and writing object variables based on the intermediate code Code detection means,
Program to function as.

Images