CN106909498B

CN106909498B - Method and system for injecting fault into Java program

Info

Publication number: CN106909498B
Application number: CN201510975340.0A
Authority: CN
Inventors: 王帅
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2015-12-22
Filing date: 2015-12-22
Publication date: 2020-12-22
Anticipated expiration: 2035-12-22
Also published as: CN106909498A

Abstract

The embodiment of the application discloses a method and a system for injecting faults into a Java program. The method comprises the following steps: the client receives an input fault code and transmits the fault code to the master control end; after a Java virtual machine is started, loading an original Class file; the master control end monitors the running condition of a Java process in which the Java virtual machine is positioned, and retrieves the original Class file loaded by the Java virtual machine; the master control end edits the retrieved original Class file according to the fault code to generate an edited Class file; the master control end uploads the edited Class file to the Java virtual machine to replace the original Class file; and the Java virtual machine interprets and executes the edited Class file. By the aid of the method and the device, fault injection after the Java virtual machine is started can be achieved.

Description

Method and system for injecting fault into Java program

Technical Field

The application relates to the technical field of computer software, in particular to a method and a system for injecting faults into a Java program.

Background

In the software development process, reliability verification is often required to be performed on a developed program. It is generally possible to detect whether an exception condition is generated by a program to be verified by introducing a fault to the program to be verified. By introducing faults, system failure can be accelerated, so that system errors can be simulated in a short time, failure data of the system can be obtained, and the fault tolerance performance and stability of the program to be verified can be evaluated. Fault injection techniques generally include hardware-based fault injection, software-based fault injection, and simulation-based fault injection.

A typical software-based fault injection method may be implemented by dynamically modifying the data in the registers used by the processes. In a computer system, a process is a running activity of a program with independent functionality with respect to a certain data set. It can apply for and own system resources, and is a dynamic concept. It is not just the code of the program but also the current activity, indicated by the contents of the processing registers. When a process is running, state is typically stored in registers. In order to evaluate the recoverability, fault tolerance and availability of the whole system after certain processes in a software system fail, a set of fault injection tools based on computer system registers is provided in the prior art, and the module can be applied to x86 and x64 series Linux systems.

In an operating system, a plurality of processes generally need to be run, and CPU resources need to be shared among the processes. The operating system is responsible for scheduling and switching among processes, and when the system needs to schedule the processes, it needs to ensure that data cannot be damaged in the process of switching the processes. Therefore, the operating system will first save the current state (mainly the register contents) of the process to be swapped out to the memory, and restore the state of the process to be swapped in. However, these operations all need to be completed in the presence of a system clock interrupt request. The clock interrupt request is a resource occupation statistical basis for task scheduling and process switching in the operating system, and is the working pulse of the kernel of the whole operating system. That is, when a system clock interrupt occurs, the operating system may perform a switching operation of processes, followed by completion of a field recovery operation. Therefore, when the system clock is interrupted, the backup register data in the memory can be modified in a software mode before the system performs field recovery operation, and then the operating system can recover the modified register content to the process register, so that the purpose of software fault injection is achieved.

For Java programs, the above approach does not enable fault injection. This is because a software system written in the Java language needs to be interpreted and executed by a Java virtual machine, and an operating system cannot be directly executed.

In the process of developing a Java program, after a programmer writes Java source code, the Java source code can be compiled by a Java compiler into a bytecode file (Class file) that can be executed by a Java virtual machine. Furthermore, the Java virtual machine interprets and executes the byte code file, so that the running of the program can be realized. After the Java virtual machine is started, before the Class file is interpreted and executed, the Java virtual machine needs to complete 5 stages of loading, verifying, preparing, parsing and initializing the Class file. Under normal circumstances, the Class file is loaded once by the Java virtual machine.

In the prior art, a fault injection tool for Java programs uses bytecode modification software to modify compiled Class files before a Java virtual machine is started, so as to achieve the purpose of statically injecting Java program faults. The tool needs to collect corresponding fault information in advance, scan and match class files, inject corresponding fault codes, and start a Java virtual machine to execute corresponding byte code files.

However, the tool is only suitable for modifying the class bytecode file before the Java virtual machine is started, and the fault injection tool cannot complete fault injection after the Java virtual machine is started. In a test environment, if a tester wants to reproduce a fault scene, the executing Java virtual machine needs to be shut down, then the bytecode file is modified, and the Java virtual machine is restarted, at this time, the Java virtual machine cannot recover original fault context information. In particular, the system error report when the fault occurs, and when the error needs to be reproduced, various parameters and phenomena in the previous error report may not be reproduced due to the restart of the Java virtual machine.

Disclosure of Invention

The embodiment of the application aims to provide a method and a system for injecting a fault into a Java program, so as to realize fault injection after a Java virtual machine is started.

In order to solve the above technical problem, the embodiment of the present application is implemented as follows:

a method for injecting faults into a Java program comprises the following steps:

the client receives an input fault code and transmits the fault code to the master control end;

after a Java virtual machine is started, loading an original Class file;

the master control end monitors the running condition of a Java process in which the Java virtual machine is positioned, and retrieves the original Class file loaded by the Java virtual machine;

the master control end edits the retrieved original Class file according to the fault code to generate an edited Class file;

the master control end uploads the edited Class file to the Java virtual machine to replace the original Class file;

and the Java virtual machine interprets and executes the edited Class file.

A system for Java program fault injection, comprising:

the client is used for receiving the input fault code and transmitting the fault code to the master control end;

the master control end is used for monitoring the running condition of a Java process in which the Java virtual machine is positioned and retrieving an original Class file loaded by the Java virtual machine; editing the retrieved original Class file according to the fault code to generate an edited Class file; uploading the edited Class file to the Java virtual machine to replace the original Class file;

and the Java virtual machine is used for loading the original Class file after being started and for interpreting and executing the edited Class file.

According to the technical scheme provided by the embodiment of the application, after the Java virtual machine is started, the running condition of the Java virtual machine is monitored, the loaded original Class file is retrieved, and the edited Class file is generated by editing to replace the original Class file, so that the fault of a specified type can be realized under the condition that the Java virtual machine does not need to be restarted after the Java virtual machine is started, and the context data in error reporting can be kept.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.

FIG. 1 is a JVM TI interaction model according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating an embodiment of a method for injecting a fault into a Java program according to the present application;

fig. 3 is a system embodiment of injecting a Java program into a fault according to the present application.

Detailed Description

The embodiment of the application provides a method and a system for injecting faults into a Java program.

In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

After the programmer writes the Java source code, the Java source code can be compiled by a Java compiler into bytecode (Class file) that can be interpreted and executed by a Java virtual machine. After the Java virtual machine is started, the loading, verification, preparation, analysis, initialization and other works of the Class file are completed, and then the Class file is interpreted and executed. Under normal conditions, after the Java virtual machine is started, the Class file can be loaded only once.

In an embodiment of the method for injecting the fault in the Java program, the method includes a jvm ti interaction model as shown in fig. 1.

As shown in fig. 1, the system comprises a client, a master control end and a target Java process. The target Java process may include an Agent (Agent), a JVM Tool Interface (JVM (Java virtual machine) Tool Interface, JVMTI), and a Java program (Java Application).

The JVMTI can run in the same Java virtual machine together with the Java program, and is responsible for monitoring and maintaining the Java program. When other programs need to communicate with the JVMTI, a JVMTI Agent, i.e., Agent, may be created. The created Agent and the target Java virtual machine can be executed on the same process, and the Agent can be used as a medium for interaction between the JVMTI and the outside.

The client is an interface for user interaction, and all operation behaviors of a user can be completed at the client. After the user edits the fault injection code through the client, the fault code can be uploaded to the master control end through the client.

The master control end can communicate with the client end, and analyzes the instruction information from the client end to obtain the parameters in the fault codes. On the other hand, the master control end can monitor the execution state of the Java process, can interact with the Agent and further can send control information to the JVMTI in the Java process. Specifically, after the Java virtual machine is started and finishes loading the Class file, the master control end can retrieve the loaded Class file from the Java virtual machine, modify the Class file, and then transmit the modified Class file back to the Java virtual machine to replace the original Class file. In the process, on one hand, the master control end can communicate with the client, and analyzes the instruction information from the client to obtain the fault code. On the other hand, the master control end can retrieve the Class file loaded after the Java virtual machine is started. Furthermore, the master control end can edit the retrieved Class file according to the fault code to generate an edited Class file. After the edited Class file is generated, the master control end can upload the edited Class file to the Java virtual machine to replace the original Class file.

Fig. 2 shows an embodiment of a method for fault injection of a Java program according to the present application, and as shown in fig. 2, the method includes:

s210: the client receives the input fault code and transmits the fault code to the master control end.

As mentioned above, the client is an interface for user interaction, and all the operation actions of the user can be completed at the client. Specifically, the client may include an operation console and a communication module. The operation console can be used as an interactive interface for a user to submit a fault code and receive an operation instruction issued by the user. The communication module can upload the fault codes to the master control end.

The operator console may include a script editor. The script editor can provide the user with the editing function of the fault injection script and assist the user in editing the fault codes in the mode of editing the fault injection script. Specifically, the script editor may provide operations to modify Class names, method names, and operational behaviors; thus, the user can use the script editor to make the Class name, method name and operation behavior to be modified as the injection script.

The client-side can also comprise a script checking module used for verifying whether the script edited by the user meets the specification.

The master control end can communicate with the client end in a Socket mode, and analyzes the instruction information from the client end to obtain the fault code. By adopting a Socket programming technology, the monitoring port is opened at the master control end, so that the Class file of the same running Java virtual machine can be modified for many times. Therefore, when a new fault injection request exists, the client side sends the fault injection script to the master control side in a Socket connection mode, and the master control side can analyze the fault injection script submitted by the client side.

S220: the Java virtual machine starts and loads the original Class file.

This step is similar to the prior art and is not described again.

It should be noted that S220 and S210 do not have a strict sequence, S220 may be executed before or after S210, and S220 may also be executed in parallel with S210.

S230: and the master control end monitors the running condition of the Java process in which the Java virtual machine is positioned and retrieves the original Class file loaded by the Java virtual machine.

As previously mentioned, a Java process may include an agent and a Java virtual machine. In other words, the Agent may execute on the same process as the Java virtual machine. The JVMTI and Java program may run together in the Java virtual machine. The JVMTI may listen to and maintain the Java program. The Agent can be used as a medium for JVMTI to interact with the outside world. The JVMTI related interface call information may be transferred to the Agent.

The master control end can be designed as a servo process, monitors the execution state of the Java process and interacts with the Agent. Through the Agent, the master control end can send out control information related to the JVMTI.

Specifically, in this step, the master control end may monitor the operating condition of the Java virtual machine through the JVMTI, and retrieve the original Class file after monitoring that the Java virtual machine loads the original Class file. Further, the general control end may include a bytecode retrieval module, and the original Class file loaded by the Java virtual machine may be retrieved through the bytecode retrieval module. More specifically, an abstract Class Transformer can be defined in the present application, and the abstract Class Transformer can implement a Class filetransformer interface, and the Transform method thereof provides an editing process of a Class bytecode. In the Transform method, a bytecode retrieval module is used to retrieve the Class file. By using a get method of a ClassPool class, a bytecode file corresponding to a specified class name can be obtained, and a reference of a CtClass type of a class of the bytecode file is returned. The CtClass class provides a series of interfaces such as class name modification, member variable addition, instance addition and designation acquisition.

S240: and the master control end edits the retrieved original Class file according to the fault code to generate an edited Class file.

The master control end can edit the retrieved original Class file according to the fault code received in S210. Specifically, the master control end may include a bytecode editing module, and the original Class file is edited by calling javasist software. Javasissist is an open source class library for analyzing, editing and creating Java bytecodes, created by ShigeruChiba (qianyakui) of the mathematics and computer department of the university of industry, tokyo. It has added an open source code JBoss application server project, implementing a dynamic "AOP" framework for JBoss by using javasisst to operate on bytecode.

Some other similar tools, such as BCEL, ASM, are currently involved in the handling of Java bytecodes. For example, javasissst compares with ASM characteristics as follows:

1. the javasist is based on the API of the source code level, and is simpler than the ASM based on byte codes;

2. based on the javasissist development, some knowledge of the bytecode is not required to be known, and some tool classes encapsulated by the method can simply realize some high-level functions, such as HotSwaper.

3. ASM is faster and more flexible than javascript.

And editing the original Class file according to the received fault code to obtain the edited Class file. The edited Class file already has the injected fault code.

More specifically, according to the abstract class Transformer defined in the above S230, when a method of the class needs to be modified, a getMethod method may be called to obtain an instance method corresponding to the CtMethod class. The CtMethod class provides a range of functions for modifying methods, such as inserting code at a specified line, inserting code before method execution, adding exception handling information, adding local variables, resetting method bodies, and the like. After the bytecode corresponding to the Class file is edited, calling a ToBytecode method of the CtClass Class to regenerate the Class bytecode file, and finishing the modification work of the bytecode.

The Instrumentation interface is the core part of a java. The addtranformer method may register a ClassFileTransformer, while the refineclasses method may redefine a Class. The master control end can store the reference of the Instrumentation interface, so that when a new Class needing to be modified exists, the Class corresponding to the Class needs to be re-instantiated, the Transformer subclass is registered, and then the transformclass method is called.

An Agent may set a static method: agentmain method. This one static method is packed as Jar package and the value of Agent-Class is set to Agent Class name and the values of Can-Redefine-Classes and Can-retransmission-Classes are set to true in manifest. Modifying the Class bytecode file during program execution requires that Agent attach be assigned to a designated Java process. The method calls the attech method of the VirtualMachine class, returns the instance object of the VirtualMachine class corresponding to the process, and then calls the loadAgent method of the instance object to complete the attech task of the Agent. When the attach is successful, the Java virtual machine calls a corresponding agentmain method to achieve the purpose of modifying the byte codes of the Java virtual machine in the program execution process.

S250: and the master control end uploads the edited Class file to the Java virtual machine to replace the original Class file.

In this step, specifically, the master control end may call an Agent in the Java process, and upload the edited Class file to the Java virtual machine through the Agent, so that the original Class file may be replaced with the edited Class file.

Furthermore, a Transform Class can be referred to in the JVMTI communication module, the master control end uses the reference to communicate with the JVMTI in the Java virtual machine through the Agent, and the Class file generated by the bytecode editing module can be uploaded to the Java virtual machine.

S260: and the Java virtual machine interprets and executes the edited Class file.

The edited Class file comprises the injected fault code, so that the edited Class file is interpreted and executed by the Java virtual machine, fault injection can be completed, and the fault tolerance performance, stability or reliability of the program to be tested can be evaluated.

After the above steps are performed, the embodiment of the present application may further include:

s270: and the master control end transmits the fault result data back to the client.

After the fault injection is completed, the master control end can transmit the fault result data back to the client to prompt the user. Specifically, the master control end may define a data transmission class TransferProtocol, where the transmission class may be composed of a target class name (targetClass), a target method (targetMethod), a plug-in script (codes), a fault type (faultType), a fault result (faulttesult), and the like.

In addition, according to the method and the device, after the Java virtual machine is started, the running condition of the Java virtual machine is monitored, the loaded original Class file is retrieved, and the edited Class file is generated by editing to replace the original Class file, so that the fault of the specified type can be injected without restarting the Java virtual machine after the Java virtual machine is started, and the context data during error reporting can be kept.

Furthermore, by using the above embodiments of the present application, a code segment can be inserted into a specified position of the bytecode of the Java program, the execution logic of the control statement can be adjusted, the method parameters can be modified, the method can be forced to return in advance, and an exception can be thrown.

In addition, in the prior art, for a fault injection tool of a Java program, it is necessary to collect corresponding fault information in advance and establish a corresponding fault library, so that after a class file is scanned and matched, a corresponding fault code is injected, and a Java virtual machine is started to execute a corresponding bytecode file. The prior art needs to scan Java files in advance and cannot meet the purpose of injecting any fault code into byte code files. The tool cannot achieve the purpose of injecting faults into the running Java virtual machine. Compared with the prior art, the fault library does not need to be established, and any fault code can be injected into the byte code file.

The embodiments of the present application also provide a system, which can implement the above method steps, and the system can be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, a system in a logical sense is formed by reading a corresponding computer program instruction into a memory by a Central Processing Unit (CPU) of a server to run.

Specifically, the system for injecting a fault into a Java program according to the present application may be as shown in fig. 3, and includes:

the client terminal 31 is used for receiving the input fault code and transmitting the fault code to the master control terminal;

the master control end 32 is used for monitoring the running condition of a Java process in which the Java virtual machine is positioned and retrieving an original Class file loaded by the Java virtual machine; editing the retrieved original Class file according to the fault code to generate an edited Class file; uploading the edited Class file to the Java virtual machine to replace the original Class file;

the Java virtual machine 33 is used for loading the original Class file after being started and for interpreting and executing the edited Class file.

In one embodiment, preferably, the client may include an operation console and a communication module, wherein:

the operation console is used as an interactive interface for submitting fault codes by a user and receives operation instructions issued by the user;

and the communication module uploads the fault code to a master control end.

In an embodiment, preferably, the master control end may communicate with the client in a Socket manner.

In one embodiment, preferably, the client may further include a script checking module for verifying whether the script edited by the user meets the specification.

In an embodiment, preferably, the master control end may monitor the operating condition of the Java virtual machine through the JVMTI, and retrieve the original Class file after monitoring that the Java virtual machine loads the original Class file.

In one embodiment, the master control terminal is preferably designed as a servo process.

In one embodiment, preferably, the master control end edits the original Class file by calling any one of the following software:

Javassit，BCEL，ASM。

in one embodiment, preferably, the master control end uploads the edited Class file to the Java virtual machine through Agent by calling Agent in the Java process, so as to replace the original Class file.

In an embodiment, preferably, the master control end may further include a return module, configured to return the fault result data to the client.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, MicrochipPIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for injecting a fault into a Java program, comprising:

after a Java virtual machine is started, loading an original Class file;

the master control end edits the retrieved original Class file according to the fault code to generate an edited Class file; wherein, the editing of the original Class file comprises at least one of the following modes: inserting code segments, adjusting execution logic of control statements and modifying method parameters;

and the Java virtual machine interprets and executes the edited Class file.

2. The method of claim 1, wherein the client comprises an operating console and a communication module, wherein:

and the communication module uploads the fault code to a master control end.

3. The method of claim 1, wherein the master control end communicates with the client in a Socket manner.

4. The method of claim 1, wherein the client further comprises a script checking module for verifying whether a script edited by a user complies with a specification.

5. The method as claimed in claim 1, wherein the step of the master control end monitoring the running condition of the Java process of the Java virtual machine and retrieving the original Class file loaded by the Java virtual machine comprises:

and the master control end monitors the running condition of the Java virtual machine through JVMTI, and retrieves the original Class file after monitoring that the original Class file is loaded by the Java virtual machine.

6. The method according to claim 1, wherein the master control end is designed as a servo process.

7. The method as claimed in claim 1, wherein the master control end implements editing of the original Class file by calling any one of the following software:

Javassit，BCEL，ASM。

8. the method as claimed in claim 1, wherein the uploading the edited Class file to the Java virtual machine by the master terminal to replace the original Class file comprises:

and the master control end uploads the edited Class file to a Java virtual machine through the Agent by calling the Agent in the Java process so as to replace the original Class file.

9. The method of claim 1, wherein the method further comprises:

and the master control end transmits the fault result data back to the client.

10. A system for Java program fault injection, comprising:

the master control end is used for monitoring the running condition of a Java process in which the Java virtual machine is positioned and retrieving an original Class file loaded by the Java virtual machine; editing the retrieved original Class file according to the fault code to generate an edited Class file; uploading the edited Class file to the Java virtual machine to replace the original Class file; wherein, the editing of the original Class file comprises at least one of the following modes: inserting code segments, adjusting execution logic of control statements and modifying method parameters;

11. The system of claim 10, wherein the client comprises an operating console and a communication module, wherein:

and the communication module uploads the fault code to a master control end.

12. The system of claim 10, wherein the master control end communicates with the client in a Socket manner.

13. The system of claim 10, wherein the client further comprises a script checking module for verifying that a script edited by a user complies with a specification.

14. The system as claimed in claim 10, wherein the master control end monitors the running condition of the Java virtual machine through JVMTI, and retrieves the original Class file after monitoring that the Java virtual machine loads the original Class file.

15. The system of claim 10, wherein the master control is configured as a servo process.

16. The system of claim 10, wherein the master control end edits the original Class file by calling any one of the following software:

Javassit，BCEL，ASM。

17. the system as claimed in claim 10, wherein the master control end uploads the edited Class file to the Java virtual machine through Agent by calling Agent in the Java process, so as to replace the original Class file.

18. The system according to claim 10, wherein the master control end further comprises a back-transmission module for transmitting the fault result data back to the client.