CN113127329B

CN113127329B - Script debugging method and device and computer storage medium

Info

Publication number: CN113127329B
Application number: CN201911414535.2A
Authority: CN
Inventors: 陈勇
Original assignee: Beijing Huawei Digital Technologies Co Ltd
Current assignee: Beijing Huawei Digital Technologies Co Ltd
Priority date: 2019-12-31
Filing date: 2019-12-31
Publication date: 2023-06-20
Anticipated expiration: 2039-12-31
Also published as: CN113127329A

Abstract

The application discloses a script debugging method, a script debugging device and a computer storage medium, and belongs to the technical field of computers. In the application, the proxy module and the script execution engine can be arranged in the container in advance, and the breakpoint trigger configuration information is registered so that in the process of executing the script through the script execution engine, if any one of the one or more breakpoints registered in advance is executed through the script execution engine, the breakpoint trigger configuration information is registered; the agent module judges whether the breakpoint meets the breakpoint debugging condition based on the breakpoint trigger configuration information, and the judgment by the debugger is not needed, so that the script execution engine which does not support the debugging function can finally have the debugging function, the interaction times between the debugger and the container in the debugging process are further reduced, and the script debugging efficiency is further improved.

Description

Script debugging method and device and computer storage medium

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a script debugging method, a script debugging device, and a computer storage medium.

Background

The script includes a plurality of computer-executable commands, and the script is executed by a script execution engine to implement the functions of the script. In the process of executing the script by the script execution engine, the script is usually debugged to locate the problem in the script.

In the related art, a script execution engine is typically deployed in a container, and the script execution engine does not have a debugging function, so in order to implement debugging of a script, a debugger needs to be configured for the container. The debugger may communicate with the container. When the debugger receives a debugging instruction sent by the client, a breakpoint request instruction is sent to the container based on a target script breakpoint carried in the debugging instruction, wherein the breakpoint request instruction carries the target script breakpoint. When the container is executed to the position indicated by the target script breakpoint through the script execution engine, a debugging trigger instruction is sent to the debugger. When the debugger receives the debugging trigger instruction, if the current breakpoint debugging condition is determined to be met, script debugging is performed, and a debugging result is displayed. If it is determined that the breakpoint debug condition is not currently satisfied, the debugger returns a resume execution command to the container.

In the process of debugging the script, the container and the debugger are required to interact for a plurality of times, if the container and the debugger are not located in the same network environment, the time required by the debugging process is long, and thus the debugging efficiency is very low.

Disclosure of Invention

The embodiment of the application provides a script debugging method, a script debugging device and a computer storage medium. The technical scheme is as follows:

in one aspect, a script debugging method is provided, and the method is applied to a container, wherein a script execution engine and an agent module are deployed in the container, one or more breakpoints and breakpoint trigger configuration information are registered in the container, and the breakpoint trigger configuration information is used for indicating whether a breakpoint meets breakpoint debugging conditions. In the method, executing a script by the script execution engine; invoking the proxy module to detect any one of the one or more breakpoints based on the breakpoint trigger configuration information if executed by the script execution engine to the any one of the one or more breakpoints; and under the condition that the agent module detects that any breakpoint does not meet the breakpoint debugging condition, continuing to execute the script through the script execution engine.

In the method, the agent module and the script execution engine can be arranged in the container in advance, and the breakpoint trigger configuration information is registered, so that whether the breakpoint meets the breakpoint debugging condition can be conveniently judged by the agent module based on the breakpoint trigger configuration information, judgment by a debugger is not needed, the script execution engine which does not support the debugging function can finally have the debugging function, the interaction times between the debugger and the container in the debugging process are further reduced, and the script debugging efficiency is further improved.

Optionally, after the invoking the proxy module detects the any breakpoint based on the breakpoint trigger configuration information, the invoking further includes: and under the condition that the agent module detects that any breakpoint meets the breakpoint debugging condition, sending a debugging trigger instruction to a debugger, wherein the debugging trigger instruction is used for indicating the debugger to debug any breakpoint based on the debugging trigger instruction.

That is, in the process that the container executes the script through the script execution engine, the container interacts with the debugger only when the agent module detects that the breakpoint meets the breakpoint debugging condition, so as to trigger the debugger to debug the breakpoint. When the agent module detects that the breakpoint does not meet the breakpoint debugging condition, the container does not need to interact with the debugger, and the script execution engine is directly and continuously restored to continuously execute the script.

Optionally, the method further comprises: receiving a container starting instruction; loading the agent module and the script execution engine;

receiving a breakpoint configuration request sent by a debugger, wherein the breakpoint configuration request carries the one or more breakpoints and the breakpoint trigger configuration information; registering the one or more breakpoints in the script execution engine, and registering the breakpoint trigger configuration information in the proxy module.

Since a part of the debugging function needs to be performed by replacing the debugger in the related art with the proxy module, it is necessary to register some information for debugging in the container in advance. These information include one or more breakpoints to debug, and breakpoint trigger configuration information. The breakpoint trigger configuration information is used for indicating whether a breakpoint meets a breakpoint debugging condition. The method is convenient for the subsequent container to reduce the interaction times with the debugger when executing the script through the script execution engine so as to complete the efficient script debugging process.

Optionally, the breakpoint trigger configuration information includes a plurality of key information and class information corresponding to each key information in the plurality of key information, and each breakpoint is associated with one or more key information in the plurality of key information; the invoking the proxy module to detect any breakpoint based on the breakpoint trigger configuration information includes: determining class information corresponding to the key information associated with any breakpoint from the breakpoint trigger configuration information; acquiring the value of the local variable corresponding to any breakpoint from the determined class information; and if the value of the local variable is inconsistent with the value required by the script execution engine to execute any breakpoint, detecting that any breakpoint does not meet the breakpoint debugging condition.

Correspondingly, after the value of the local variable corresponding to the any breakpoint is obtained from the determined class information, the method further comprises: and if the value of the local variable is consistent with the value required by the script execution engine to execute any breakpoint, detecting that any breakpoint meets the breakpoint debugging condition.

In one possible implementation manner, the proxy module can judge whether the breakpoint meets the breakpoint debugging condition through the above manner, so as to reduce the number of interactions between the container and the debugger.

In another aspect, a script debugging device is provided, where the structure of the script debugging device includes a processor and a memory, and the memory is used for storing a program supporting the script debugging device to implement the script debugging method provided above, and storing data related to the script debugging method provided above. The processor is configured to execute a program stored in the memory. The operating means of the memory device may further comprise a communication bus for establishing a connection between the processor and the memory.

In another aspect, a computer readable storage medium having instructions stored therein that, when executed on a computer, cause the computer to perform the script debugging method provided above is provided.

In another aspect, a computer program product is provided comprising instructions that, when executed on a computer, cause the computer to perform the script debugging method provided above.

Drawings

FIG. 1 is a schematic diagram of a script debugging system according to an embodiment of the present application;

FIG. 2 is a flowchart of a script debugging method provided in an embodiment of the present application;

FIG. 3 is a schematic diagram of interactions between a container and a debugger according to embodiments of the present application;

FIG. 4 is a flowchart of another script debugging method provided by an embodiment of the present application;

FIG. 5 is a block diagram of a script debugging device provided in an embodiment of the present application;

FIG. 6 is a block diagram of another script debugging device provided by an embodiment of the present application;

fig. 7 is a schematic structural diagram of another computer device according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Before explaining the embodiment of the present application in detail, an application scenario of the embodiment of the present application is explained.

Scripts are executable files written in accordance with a certain format using a specific descriptive language. Scripts are also known as scripting languages (Script languages, scripting programming languages, scripting languages, etc.). Scripts are computer programming languages created to shorten the traditional write-compile-link-run (edit-link) process. This naming originates from a script "screenplay" that causes the dialog box to be repeated word by word each time the script is run. Early scripts were often referred to as batch or work control languages. A script is typically interpreted to run rather than compiled. While many scripts have exceeded the field of computer simple task automation, matured to the point where sophisticated programs can be written, they are still known as scripts. Almost all computer systems have a script at each level. Including an operating system layer such as a computer game, web application, word processing document, web software, etc. In many aspects, high-level programming languages and scripts are interdigitated with no explicit boundaries between them. A script may automate the interactive operations that would otherwise be performed with the keyboard. A script consists essentially of commands that would otherwise need to be entered in a command line, or in a text editor, a user can use the script to combine some of the usual operations into a set of sequences. Many scripts actually have exceeded the instructions of a simple user command sequence and can also write more complex programs.

Scripts are typically executed with a corresponding script execution engine. There are many types of scripts and many types of script execution engines, and different types of scripts require different types of script execution engines to execute. Only if the script type corresponds to the script execution engine type, the script can be executed correctly.

The script execution engine, which is an interpreter of a computer programming language, functions to execute the user's program text (i.e., script) and translate it into machine code that can be executed by a computer, thereby completing a series of functions.

Commonly used script execution engines can be broadly divided into three categories:

one is to compile scripts directly into class (class) files, without a separate script execution engine, directly using the debug capabilities of the java debug interface (Java Debug Interface, JDI) JDI. The script execution engine comprises script language description, execution and debugging functions. This type of script execution engine typically includes groovy, scala, kotlin, fantom, jython, jruby and the like. Since such script execution engines do not require a separate engine to debug, they are not within the scope of the discussion of the present application.

The other is a script execution engine providing debugging functions, which supports actions such as breaking points, single-step execution and the like when the script execution engine executes a script. This type of script execution engine typically includes python, perl, PHP, ruby, LUA, ANT, xslt and the like. Since the script execution engine is required to support the debugging function, execution runs in the execution engine together with the debugged code, which can be classified as an intrusive debugging technique.

Another type is a script execution engine without debug capabilities, which the authorities claim to be without debug capabilities, such as script execution engines typically include freemarker, BPMN, smooks, gradle, shell, drools and the like.

Each script engine needs to implement a debugging function, and based on the above, many script engines currently do not provide a debugging function, so that the scripts cannot be debugged. When the script is developed, whether the script has a problem or not can be determined only by looking up information such as an execution log, an execution result and the like in the running environment. After the problem is found, the location of the problem in the script cannot be located directly. At this time, the problem location is usually found by a dichotomy method in which a script is executed again after deleting a part of the script. Resulting in long development cycle and low development efficiency.

Whereas if the debug function is supported directly at the script execution engine, it is necessary to modify the code in the script execution engine, which typically takes a long time. And if the debug and run functions are performed together, adding the debug function may cause the run function to be problematic. The script execution engine is generally open-source, and is difficult to receive the integration of the debugging function with large influence of the function. Therefore, there is a need to study a method of debugging scripts by a script execution engine without a debugging function.

The script debugging method provided by the embodiment of the application is applied to a scene of how to realize the debugging of the script when the script execution engine has no debugging function.

Fig. 1 is a schematic architecture diagram of a script debugging system according to an embodiment of the present application. As shown in fig. 1, the system 100 includes a container 101 and a debugger 102. The embodiment of the present application does not limit the number of containers 101 and debuggers 102, and fig. 1 only illustrates 1 container 101 and one debugger 102 as an example. Debugger 102 may communicate with container 101.

The container 101 in fig. 1 may be deployed/run on a virtual machine. A script execution engine that performs script compilation is disposed in the container 101. Taking the Java container as an example, the Java container may specifically refer to a Java process running a script execution engine. When starting the Java container, the debugging features of the Java virtual machine can be started by using relevant parameters of the vulnerability tool. The script execution engine in the Java container may refer to a package having script parsing execution capability.

The debugger 102 is provided with a debug plug-in, and the debugger 102 communicates with the container 101 through the debug plug-in to realize a debug function for the script.

The interface used in the communication between debugger 102 and container 101 may be a debug interface such as JDI. The JDI is the interface of the highest layer of the three layers of modules included in the Java platform debug architecture ((Java platform Debugger architecture, JPDA) and defines some debug interfaces required by a Debugger (debug). Based on these interfaces, the Debugger can know the state of the target virtual machine in time, for example, see which classes and instances are on the target virtual machine, etc.

Currently, most JDI debugger implementations are written in the Java language. For example, java developers are again familiar with the Eclipse IDE, intellij IDEA, which is not yet familiar with.

In addition, in the embodiment of the present application, in order to avoid too many interactions between the debugging script process container 101 and the debugger 102, a proxy module is disposed in the container 101, where the proxy module may implement some judgment operations of the debugger 102 in the related art, so as to reduce the number of interactions between the debugging script process container 101 and the debugger 102. The relevant functions of the proxy module will be explained in detail in the following method embodiments, which are not explained here.

Illustratively, taking a Java container as an example, the Java container is deployed on a Java virtual machine. The Java virtual machine tool interface (JVMTool Interface, JVMTI) is a native programming interface provided by the Java virtual machine, and is an updated version of the Java virtual machine performance analyzer (Java Virtual Machine Profiler Interface, JVMPI) and the Java virtual machine debug interface (Java Virtual Machine Debug Interface, JVMTI). From this development history trace of the application program interface (application interface, API), it is known that JVMTI provides an interface that can be used for debugging (debug) and performance analysis (profiler); meanwhile, in Java 5/6, the virtual machine interface is also added with functions such as Monitoring (Monitoring), thread analysis (Thread analysis), coverage rate analysis (Coverage Analysis) and the like. It is the basis for implementing Java debuggers and other Java runtime test and analysis tools, due to the powerful functions of JVMTI.

That is, the JVMTI is a set of native code interface of the Java virtual machine, so during development, the JVMTI may be used by deploying an Agent module (Agent), the Agent module uses JVMTI functions, sets some callback functions, obtains current running state information from the Java virtual machine, makes own judgment, and finally may also operate the running state of the virtual machine, so as to implement the function of the Agent module provided by the embodiment of the present application.

In addition, the agent module may be compiled into a dynamic link library, and after the agent module is compiled into a dynamic link library, it may be loaded at the time of starting the Java program (start-up loading mode), or may be loaded at the time of using the runtime after the Java 5 (active loading mode). So that the subsequent container performs some operations through the proxy module.

When it is to be noted, JVMTI is not necessarily implemented on all Java virtual machines, and the implementation of different virtual machines is not identical. However, in some mainstream virtual machines, such as Sun and IBM, and in some open sources, such as Apache Harmony DRLVM, a standard JVMTI implementation is provided.

The deployment agent module is only described by taking JVMTI as an example, and the configuration of the agent module can be implemented by other implementation manners, and only the container can implement the script execution method provided by the embodiment of the application through the configured agent module.

The script debugging method provided by the embodiment of the application is explained below. Based on the above system architecture, a part of the debug function can be performed by the proxy module instead of the debugger in the related art, and thus, some information for debug needs to be registered in the container in advance. These information include one or more breakpoints to debug, and breakpoint trigger configuration information. The breakpoint trigger configuration information is used for indicating whether a breakpoint meets a breakpoint debugging condition. The method is convenient for the subsequent container to reduce the interaction times with the debugger when executing the script through the script execution engine so as to complete the efficient script debugging process. Therefore, the script debugging method provided by the embodiment of the application may include the following two processes: firstly registering a breakpoint and a process of triggering configuration information by the breakpoint, and secondly, a script debugging process in a script execution process. The following two examples are provided to illustrate the two processes, respectively.

Fig. 2 is a schematic flow chart of a script debugging method according to an embodiment of the present application. The above-described process of registering breakpoint and breakpoint trigger configuration information is explained in detail. As shown in fig. 2, the method comprises the following steps:

Step 201: the container receives a container activation instruction.

Script debugging is typically triggered by a developer and the developer's client is connected to the debugger, so in one possible implementation, when the client detects a debug instruction triggered by the developer through a preset operation, the client sends a script debugging initiation request to the debugger. When the debugger receives the script debugging starting request, a locally deployed debugging plug-in is started, and a callback interface is registered through the debugging plug-in, so that the debugger establishes communication connection with the container through the callback interface. The debugger then sends a container launch instruction to the container, which when received, loads the proxy module and script execution engine by step 202 described below. The above-described process may be represented by the interaction process between the container and the debugger shown in fig. 3, and will not be described in detail herein.

The container startup instruction sent by the debugger to the container carries configuration information of the proxy module, where the configuration information of the proxy module is used to indicate a dynamic library location of the proxy module, and the dynamic library location may be any location in a system where the container is located, so that a subsequent container loads the proxy module through step 202. Illustratively, taking the java container as an example, the dynamic library location may be configured by a startup parameter java agent (java agent) or loaded by a local agent (loadAgent) function of a virtual machine (virtual machine) in the java specification, which will not be described in detail herein.

In addition, taking a Java container as an example, the above-mentioned communication connection between the debugger and the container may be used to establish a socket (socket) connection between the debugger and the Java container for sending the subsequent JDI debug command.

Step 202: the container loads the proxy module and the script execution engine.

Based on the step 201, the container start instruction further carries configuration information of the proxy module, so that the container can initialize the proxy module, that is, load the proxy module, based on the configuration information of the proxy module. In the embodiment of the present application, since the judgment of the breakpoint debug condition needs to be performed by the proxy module, as shown in fig. 3, after initializing the proxy module, the breakpoint event callback function needs to be registered in the proxy module. The breakpoint event callback function is used for judging whether a breakpoint meets a designated breakpoint debugging condition.

The manner in which the script execution engine is loaded (i.e., the script execution engine is initialized) with the container is not described in detail herein.

Step 203: the container receives a breakpoint configuration request sent by the debugger, wherein the breakpoint configuration request carries one or more breakpoints and breakpoint trigger configuration information.

As shown in fig. 3, after the container has loaded the proxy module and the script execution engine, an initialization complete message may also be sent to the debugger. After the debugger receives the initialization completion message, one or more breakpoints to be debugged are determined, and the configuration information is triggered by the breakpoints. The breakpoint trigger configuration information is used for indicating whether a breakpoint meets a breakpoint debugging condition. The debugger then sends a breakpoint configuration request to the container, the breakpoint configuration request carrying the one or more breakpoints, and breakpoint trigger configuration information.

Alternatively, after the container loads the proxy module and the script execution engine, the initialization completion message may not be sent to the debugger. In this case, the debugger may start timing when sending the container start instruction, and directly send the breakpoint configuration request to the debugger when the timing duration reaches the reference duration, so as to further reduce the number of interactions between the container and the debugger. The reference time period may be configured by a developer at the development end and will not be described in detail herein. For example, the debugger may send the breakpoint configuration request to the container 5 seconds after sending the container start instruction.

The debugger needs to determine the one or more breakpoints and the breakpoint trigger configuration information before sending the breakpoint configuration request. In one possible implementation, as shown in fig. 3, the implementation of the debugger determining the one or more breakpoints may be: the debugger can determine key codes in the script through the debugging plug-in to obtain one or more key codes, and each obtained key code is set as a breakpoint. Wherein the developer may open the script through the debug plug-in and then set the critical code to cause the debugger to obtain the one or more critical codes.

In one possible implementation manner, the implementation process of determining the breakpoint trigger configuration information by the debugger may be: after determining the one or more break points, the debugger acquires class (class) information corresponding to key information associated with each break point in a first mapping table to obtain a plurality of key information and class information corresponding to each key information in the plurality of key information, wherein each break point is associated with one or more key information in the plurality of key information. In the script, class information corresponding to the key information is used for indicating the context of the corresponding key information. The key information associated with each breakpoint includes information such as a key in the line code where the breakpoint is located, and the key may be ServiceTaskBeginNode, serviceTaskEndNode.

The first mapping table may be a mapping table between key information and class information. Table 1 is a first mapping table provided in the embodiment of the present application, and as shown in table 1, the first mapping table includes class information corresponding to each piece of key information. Because different script lines may include the same key information, in order to accurately find class information corresponding to the key information associated with the breakpoint according to the location of the breakpoint, the first mapping table further includes the script line where the key information is located.

TABLE 1

In addition, the class information corresponding to each piece of key information may further include a local variable corresponding to the key information, that is, the key information associated with each breakpoint further corresponds to a local variable, so as to determine whether the breakpoint meets the breakpoint debug condition according to the value of the local variable corresponding to the key information associated with each breakpoint.

The local variables corresponding to the key information can be obtained from a second mapping table, wherein the second mapping table is provided with a plurality of key information and a plurality of local variables corresponding to the key information one by one. Table 2 is a second mapping table provided in an embodiment of the present application. As shown in table 2, each key information may correspond to a local variable. In addition, some key information is not directly available on the top stack, and may be found on stacks of other levels. Therefore, the second mapping table further includes a stack number, where the stack number is used to indicate what layer of stack is used to obtain the key information of the line.

TABLE 2

That is, the breakpoint trigger configuration information includes a plurality of key information and class information corresponding to each of the plurality of key information, and the class information further includes a local variable. Each of the preset one or more breakpoints is associated with one or more pieces of key information of the plurality of pieces of key information.

The key information, class information, and local variables in the above tables 1 and 2 are described by taking a Java container as an example, and the debug interface is JDI or an interface based on the Java debug line protocol (Java Debug Wire Protocol, JDWP). The container in the embodiment of the present application is not limited to a Java container, and may be a container where a script execution engine directly compiled in a language such as c++, where loading of the proxy module may be implemented in other manners (for example, may be a manner of ld_library, dll injection, etc.), and the debug interface used corresponds to a debug interface of a system, for example, dbghelp (one debug tracking related module in a windows operating system) of windows, etc. In this scenario, the class information specifically refers to the compiled derived function name, and the script line refers to the offset. And will not be explained in detail here.

Step 204: the container registers one or more breakpoints in the script execution engine and registers breakpoint trigger configuration information in the proxy module.

Since the breakpoint needs to be found by the script execution engine and whether to trigger debugging needs to be determined by the proxy module, after the container receives the breakpoint configuration request, one or more breakpoints can be registered in the script execution engine, and breakpoint trigger configuration information is registered in the proxy module, so that debugging of the script is performed by the embodiment shown in fig. 4 below.

Through the embodiment shown in fig. 2, the breakpoint trigger configuration information can be registered in the proxy module of the container in advance, so that whether the breakpoint meets the breakpoint debugging condition can be judged by the proxy module conveniently, and judgment by a debugger is not needed, so that the interaction times between the debugger and the container are reduced, and the script debugging efficiency is improved.

The above embodiment is described taking the example of registering the breakpoint and the breakpoint trigger configuration information each time the script is debugged, and then debugging the script by the embodiment shown in fig. 4 described below.

Alternatively, for the same type of script, the breakpoint and breakpoint trigger configuration information are generally consistent, so the process of registering the breakpoint and breakpoint trigger configuration information in the embodiment shown in fig. 2 described above may be implemented in a container before script debugging, and then when any script belonging to the type of script needs to be debugged, it may be directly implemented by the embodiment shown in fig. 4 described below. In this scenario, the container startup instruction received by the container in step 201 is not sent by the debugger when receiving the debug instruction, but sent by the debugger when detecting that the container needs to be initialized.

Fig. 4 is a flowchart of a script debugging method according to an embodiment of the present application. The method is used for explaining the script debugging process in the script execution process in detail after registering the breakpoint and the breakpoint trigger configuration information. As shown in fig. 4, the method comprises the following steps:

step 401: the container executes the script through the script execution engine.

In one possible implementation, a developer may send a debug instruction to the container via the debugger, and after the container receives the debug instruction, the container may directly begin executing the script via the script execution engine after completing registration of the relevant information shown in fig. 2.

Optionally, after the container receives the debug instruction and completes registration of the relevant information shown in fig. 2, the container may also return a ready-complete message to the debugger. After the debugger receives the preparation completion message, the preparation completion message can be displayed, a developer can send a debugging instruction to the container again through the debugger, and when the container receives the debugging instruction, the script can be executed through the script execution engine.

Alternatively, if the relevant information in the container has been registered by the embodiment shown in fig. 2 before each script of the same type is debugged, when the debugger receives the debug instruction sent by the client, the debug instruction may be directly sent to the container, so as to trigger the container to execute the script through the script execution engine.

Step 402: in the event that execution by the script execution engine to any of the one or more breakpoints, the container call agent module detects the breakpoint based on the breakpoint trigger configuration information.

Because one or more breakpoints to be debugged are registered in the script execution engine, in the process of executing the script by the script execution engine, whether the currently executed script position is a certain breakpoint in the one or more breakpoints can be judged, if so, the script execution process is paused, and the proxy module is called to detect the breakpoint based on the breakpoint trigger configuration information, as shown in fig. 3.

Because the proxy module is registered with the breakpoint event callback function in advance, the implementation mode that the container calls the proxy module to detect the breakpoint based on the breakpoint trigger configuration information can be as follows: the agent module calls a breakpoint event callback function by taking the breakpoint as a parameter to judge whether the breakpoint meets a breakpoint debugging condition.

Based on the embodiment shown in fig. 2, the proxy module is further registered with breakpoint trigger configuration information, so that the implementation manner of calling the proxy module to detect the breakpoint based on the breakpoint trigger configuration information specifically includes: determining class information corresponding to the key information associated with the breakpoint from the breakpoint trigger configuration information; obtaining the value of the local variable corresponding to the breakpoint from the determined class information; if the obtained value of the local variable is inconsistent with the value required by the script execution engine to execute the breakpoint, the breakpoint is detected not to meet the breakpoint debugging condition. Accordingly, if the value of the local variable is consistent with the value required by the script execution engine to execute the breakpoint, it is detected that the breakpoint satisfies the breakpoint debug condition. The value required by the script execution engine to execute the breakpoint may be determined by the agent module in advance according to the location information of the breakpoint, for example, the context of the line code where the breakpoint is located may be determined according to the location information of the breakpoint, and the local variable is obtained based on the determined context, where the obtained local variable is the value required by the script execution engine to execute the breakpoint, and will not be described in detail herein.

In one possible implementation, as shown in fig. 3, after the agent detects the breakpoint, if the value output by the agent is null, it indicates that the breakpoint does not satisfy the breakpoint debug condition. At this time, the container may directly resume the script execution engine to continue executing the script through the following steps.

If the value output by the proxy module is not null, the breakpoint is indicated to meet the breakpoint debugging condition. At this time, the container calls the debugging interface to send a debugging trigger instruction to the debugger through the following steps to realize the debugging of the breakpoint.

Step 403: and under the condition that the breakpoint is detected by the proxy module not to meet the breakpoint debugging condition, the container continuously executes the script through the script execution engine.

Based on step 402, if the agent module detects that the breakpoint does not satisfy the breakpoint debug condition, the container can directly continue to execute the script through the script execution engine, and the container does not need to interact with the debugger in this scenario.

Correspondingly, under the condition that the breakpoint is detected to meet the breakpoint debugging condition through the proxy module, the container sends a debugging trigger instruction to the debugger, and the debugging trigger instruction is used for indicating the debugger to debug the breakpoint.

That is, in the embodiment of the present application, in the process that the container executes the script through the script execution engine, only when the proxy module detects that the breakpoint satisfies the breakpoint debug condition, the container interacts with the debugger to trigger the debugger to debug the breakpoint. When the agent module detects that the breakpoint does not meet the breakpoint debugging condition, the container does not need to interact with the debugger, and the script execution engine is directly and continuously restored to continuously execute the script.

After the debugger debugs the breakpoint based on the debugging trigger instruction, the debugger can also send a debugging result to the client, and the client displays the debugging result. For example, a script file is displayed in the edit window and focus is placed on the breakpoint line, a call stack is displayed in the stack window, the topmost stack is displayed as a script line, a script execution context is displayed in the local variable window, and so on.

Fig. 5 is a block diagram of a script debugging device according to an embodiment of the present application. The device is applied to a container, a script execution engine and an agent module are deployed in the container, one or more breakpoints and breakpoint trigger configuration information are registered in the container, and the breakpoint trigger configuration information is used for indicating whether one breakpoint meets a breakpoint debugging condition or not. As shown in fig. 5, the apparatus 500 includes:

An execution module 501 for executing the script by the script execution engine. The specific implementation process may refer to step 401 in the embodiment of fig. 4.

The detection module 502 is configured to, when executed by the script execution engine to any breakpoint of the one or more breakpoints, invoke the proxy module to detect any breakpoint based on the breakpoint trigger configuration information. Specific implementation may refer to step 402 in the embodiment of fig. 4.

The execution module 501 is further configured to continue executing the script through the script execution engine when the agent module detects that any breakpoint does not satisfy the breakpoint debug condition. Specific implementation may refer to step 403 in the embodiment of fig. 4.

Optionally, the apparatus 500 further includes:

the sending module is used for sending a debugging trigger instruction to the debugger under the condition that any breakpoint is detected by the proxy module to meet the breakpoint debugging condition, and is used for indicating the debugger to debug any breakpoint based on the debugging trigger instruction.

Optionally, as shown in fig. 6, the apparatus 500 further includes:

a receiving module 503, configured to receive a container startup instruction. Specific implementation may refer to step 201 in the embodiment of fig. 2.

The loading module 504 is configured to load the proxy module and the script execution engine. Specific implementation may refer to step 202 in the embodiment of fig. 2.

The receiving module 503 is further configured to receive a breakpoint configuration request sent by the debugger, where the breakpoint configuration request carries one or more breakpoints and breakpoint trigger configuration information. Specific implementation may refer to step 203 in the embodiment of fig. 2.

A registration module 505, configured to register one or more breakpoints in the script execution engine, and register breakpoint trigger configuration information in the proxy module. Specific implementation may refer to step 204 in the embodiment of fig. 2.

Optionally, the breakpoint trigger configuration information includes a plurality of key information and class information corresponding to each of the plurality of key information, and each breakpoint is associated with one or more of the plurality of key information;

a detection module 502 for:

determining class information corresponding to key information associated with any breakpoint from the breakpoint trigger configuration information;

acquiring the value of a local variable corresponding to any breakpoint from the determined class information;

if the value of the local variable is inconsistent with the value required by the script execution engine to execute any breakpoint, detecting that any breakpoint does not meet the breakpoint debugging condition.

Optionally, the detection module 502 is configured to:

if the value of the local variable is consistent with the value required by the script execution engine to execute any breakpoint, detecting that any breakpoint meets the breakpoint debugging condition.

In the embodiment of the application, the proxy module and the script execution engine can be arranged in the container in advance, and the breakpoint trigger configuration information is registered, so that whether the breakpoint meets the breakpoint debugging condition can be conveniently judged by the proxy module based on the breakpoint trigger configuration information, judgment by a debugger is not needed, the script execution engine which does not support the debugging function can finally have the debugging function, the interaction times between the debugger and the container in the debugging process are further reduced, and the script debugging efficiency is further improved.

It should be noted that: the device for triggering the intelligent network service provided in the above embodiment only uses the division of the above functional modules to illustrate when triggering the intelligent network service, in practical application, the above functional allocation may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device for triggering the intelligent network service provided in the above embodiment and the method embodiment for triggering the intelligent network service belong to the same concept, and the specific implementation process is detailed in the method embodiment, which is not described herein again.

Fig. 7 is a schematic structural diagram of a computer device according to an embodiment of the present application. The script debugging system in fig. 1 may be implemented by the computer device shown in fig. 7. Referring to fig. 7, the computer device includes at least one processor 701, a communication bus 702, a memory 703, and at least one communication interface 704.

The processor 701 may be a general purpose central processing unit (central processing unit, CPU), application Specific Integrated Circuit (ASIC), or one or more integrated circuits for controlling the execution of programs in accordance with aspects of the present application.

Communication bus 702 may include a path to transfer information between the aforementioned components.

The Memory 703 may be, but is not limited to, read-only Memory (ROM) or other type of static storage device that can store static information and instructions, random access Memory (random access Memory, RAM) or other type of dynamic storage device that can store information and instructions, but may also be electrically erasable programmable read-only Memory (EEPROM), compact disc read-only Memory (compact disc read-only Memory) or other optical disk storage, optical disk storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 703 may be separate and may be coupled to the processor 701 via a communication bus 702. Memory 703 may also be integrated with processor 701.

The memory 703 is used for storing program codes for executing the embodiments of the present application, and is controlled by the processor 701. The processor 701 is configured to execute program code stored in the memory 703. The program code may include one or more software modules, which may be modules in the embodiments shown in fig. 5 or 6. The script debugging system shown in fig. 1 may determine data for developing an application through one or more software modules in program code in the processor 701 and the memory 703.

Communication interface 704, using any transceiver-like device, is used to communicate with other devices or communication networks, such as ethernet, radio access network (radio access networkRAN), wireless local area network (wireless local area networks, WLAN), etc.

In a particular implementation, as one embodiment, a computer device may include multiple processors, such as processor 701 and processor 705 shown in FIG. 7. Each of these processors may be a single-core (single-CPU) processor or may be a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

The computer device may be a general purpose computer device or a special purpose computer device. In particular implementations, the computer device may be a desktop, laptop, web server, palmtop (personal digital assistant, PDA), mobile handset, tablet, wireless terminal device, communication device, or embedded device. Embodiments of the present application are not limited in the type of computer device.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The foregoing description of the preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, since it is intended that all modifications, equivalents, improvements, etc. that fall within the spirit and scope of the invention.

Claims

1. The script debugging method is characterized by being applied to a container, wherein a script execution engine and an agent module are deployed in the container, one or more breakpoints and breakpoint trigger configuration information are registered in the container, and the breakpoint trigger configuration information is used for indicating whether one breakpoint meets breakpoint debugging conditions or not; the method comprises the following steps:

Executing the script by the script execution engine;

invoking the proxy module to detect any one of the one or more breakpoints based on the breakpoint trigger configuration information if executed by the script execution engine to the any one of the one or more breakpoints;

under the condition that the agent module detects that any breakpoint does not meet the breakpoint debugging condition, continuing to execute the script through the script execution engine;

the method further comprises the steps of:

receiving a container starting instruction, wherein the container starting instruction carries configuration information of the proxy module, and the configuration information of the proxy module is used for indicating a dynamic library position of the proxy module, and the dynamic library position is any position of a system where the container is located; loading the proxy module based on the configuration information of the proxy module, and loading the script execution engine; receiving a breakpoint configuration request sent by a debugger, wherein the breakpoint configuration request carries the one or more breakpoints and the breakpoint trigger configuration information, and the breakpoint configuration request is sent to the container when the debugger starts timing when sending the container starting instruction and the timing time reaches a reference time; registering the one or more breakpoints in the script execution engine, and registering the breakpoint trigger configuration information in the proxy module.

2. The method of claim 1, wherein the invoking the proxy module after detecting the any breakpoint based on the breakpoint trigger configuration information further comprises:

and under the condition that the agent module detects that any breakpoint meets the breakpoint debugging condition, sending a debugging trigger instruction to the debugger, wherein the debugging trigger instruction is used for indicating the debugger to debug any breakpoint based on the debugging trigger instruction.

3. The method according to any one of claims 1 to 2, wherein the breakpoint trigger configuration information includes a plurality of key information and class information corresponding to each of the plurality of key information, each breakpoint being associated with one or more of the plurality of key information;

the invoking the proxy module to detect any breakpoint based on the breakpoint trigger configuration information includes:

determining class information corresponding to the key information associated with any breakpoint from the breakpoint trigger configuration information;

acquiring the value of the local variable corresponding to any breakpoint from the determined class information;

and if the value of the local variable is inconsistent with the value required by the script execution engine to execute any breakpoint, detecting that any breakpoint does not meet the breakpoint debugging condition.

4. The method according to claim 3, wherein after obtaining the value of the local variable corresponding to the any breakpoint from the determined class information, the method further comprises:

and if the value of the local variable is consistent with the value required by the script execution engine to execute any breakpoint, detecting that any breakpoint meets the breakpoint debugging condition.

5. The script debugging device is characterized by being applied to a container, wherein a script execution engine and an agent module are deployed in the container, one or more breakpoints and breakpoint trigger configuration information are registered in the container, and the breakpoint trigger configuration information is used for indicating whether one breakpoint meets breakpoint debugging conditions or not; the device comprises:

the execution module is used for executing the script through the script execution engine;

the detection module is used for calling the proxy module to detect any breakpoint of the one or more breakpoints based on the breakpoint trigger configuration information under the condition that the script execution engine executes to the any breakpoint;

the execution module is further configured to, when the agent module detects that the breakpoint does not meet the breakpoint debug condition, continue executing the script through the script execution engine;

The apparatus further comprises:

the receiving module is used for receiving a container starting instruction, wherein the container starting instruction carries configuration information of the proxy module, the configuration information of the proxy module is used for indicating the dynamic library position of the proxy module, and the dynamic library position is any position of a system where the container is located;

the loading module is used for loading the proxy module based on the configuration information of the proxy module and loading the script execution engine;

the receiving module is further configured to receive a breakpoint configuration request sent by the debugger, where the breakpoint configuration request carries the one or more breakpoints and the breakpoint trigger configuration information, and the breakpoint configuration request is sent to the container when the debugger starts timing when sending the container start instruction and the timing duration reaches a reference duration;

and the registration module is used for registering the one or more breakpoints in the script execution engine and registering the breakpoint trigger configuration information in the proxy module.

6. The apparatus of claim 5, wherein the apparatus further comprises:

the sending module is used for sending a debugging trigger instruction to a debugger under the condition that the agent module detects that any breakpoint meets the breakpoint debugging condition, and the sending module is used for indicating the debugger to debug any breakpoint based on the debugging trigger instruction.

7. The apparatus according to any one of claims 5 to 6, wherein the breakpoint trigger configuration information includes a plurality of key information and class information corresponding to each of the plurality of key information, each breakpoint being associated with one or more of the plurality of key information;

the detection module is used for:

8. The apparatus of claim 7, wherein the detection module is to:

9. A script debugging device, wherein the device comprises a memory and a processor;

the memory is used for storing a computer program;

The processor is configured to execute a computer program stored in the memory to perform the method of any one of claims 1-4.

10. A computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the method of any of claims 1-4.