CN113127329A

CN113127329A - Script debugging method and device and computer storage medium

Info

Publication number: CN113127329A
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: 2021-07-16
Anticipated expiration: 2039-12-31
Also published as: CN113127329B

Abstract

The application discloses a script debugging method and device and a computer storage medium, and belongs to the technical field of computers. In the application, the agent module and the script execution engine can be deployed in the container in advance, and the breakpoint triggering configuration information is registered, so that in the process of executing the script through the script execution engine, if any breakpoint in one or more previously registered breakpoints is executed through the script execution engine in the following process; whether the breakpoint meets the breakpoint debugging condition is judged by the agent module based on the breakpoint triggering configuration information without judging through a debugger, so that the script execution engine which does not support the debugging function can be finally provided with 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 improved.

Description

Script debugging method and device and computer storage medium

Technical Field

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

Background

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

In the related art, the script execution engine is usually deployed in the container, and the script execution engine does not have a debugging function, so in order to implement debugging of the 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, and the breakpoint request instruction carries the target script breakpoint. When the container is executed by the script execution engine to the position indicated by the target script breakpoint, a debugging triggering instruction is sent to the debugger. When the debugger receives the debugging triggering instruction, if the current breakpoint debugging condition is determined to be met, script debugging is carried out, and a debugging result is displayed. If the debugger determines that the breakpoint debugging 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 many times, and if the container and the debugger are not located in the same network environment, the time required by the debugging process is long, so that the debugging efficiency is very low.

Disclosure of Invention

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

on one hand, the method 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 breakpoint debugging conditions or not. In the method, a script is executed by the script execution engine; under the condition that the script execution engine executes any breakpoint in the one or more breakpoints, calling the agent module to detect the any breakpoint based on the breakpoint trigger configuration information; 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 deployed in the container in advance, and the breakpoint trigger configuration information is registered, so that whether the breakpoint meets the breakpoint debugging condition or not can be judged by the agent module based on the breakpoint trigger configuration information in the follow-up process, the judgment through a debugger is not needed, the script execution engine which does not support the debugging function can be finally provided with 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 improved.

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

That is, in the process that the container executes the script through the script execution engine, only when the agent module detects that the breakpoint meets the breakpoint debugging 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 directly continues to restore the script execution engine to continue executing the script without interacting with the debugger.

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, some information for debugging needs to be registered in the container in advance. This information includes one or more breakpoints to be debugged, and breakpoint trigger configuration information. The breakpoint trigger configuration information is used to indicate whether a breakpoint satisfies a breakpoint debugging condition. Therefore, when the subsequent container executes the script through the script execution engine, the interaction times with the debugger can be reduced so as to complete the efficient script debugging process.

Optionally, the breakpoint trigger configuration information includes a plurality of pieces of key information and class information corresponding to each piece of key information in the plurality of pieces of key information, and each breakpoint is associated with one or more pieces of key information in the plurality of pieces of key information; the invoking the agent 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; obtaining 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 the breakpoint does not meet the breakpoint debugging condition.

Correspondingly, after the obtaining the value of the local variable corresponding to any breakpoint from the determined class information, the method further includes: 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 the breakpoint meets the breakpoint debugging condition.

In a possible implementation manner, the agent module can determine whether the breakpoint satisfies the breakpoint debugging condition in the above manner, so as to reduce the number of interactions between the container and the debugger.

On the other hand, the script debugging device is provided, and the structure of the script debugging device comprises a processor and a memory, wherein the memory is used for storing a program for supporting the script debugging device to realize the provided script debugging method and storing data related to realizing the provided script debugging method. The processor is configured to execute programs 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 is provided, having stored therein instructions, which, when run on a computer, cause the computer to perform the script debugging method provided above.

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

Drawings

FIG. 1 is a schematic diagram of an architecture of a script debugging system provided in 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 an interaction between a container and a debugger, according to an embodiment of the present disclosure;

FIG. 4 is a flowchart of another script debugging method provided in the embodiments of the present application;

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

FIG. 6 is a block diagram of another script debugging apparatus provided in the embodiments of the present application;

fig. 7 is a schematic structural diagram of another computer device provided in the embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

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

Scripts are executable files written according to a certain format using a particular 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 (edge-compile-link-run) process. This naming originates from a script "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 languages or job control languages. A script is typically an interpretive run rather than a compilation. While many scripts go beyond the field of computer simple task automation, mature enough to write sophisticated programs, they are still referred to as scripts. Almost all computer systems have a script at all levels. Including operating system layers such as computer games, web applications, word processing documents, web software, and the like. In many aspects, high-level programming languages and scripts are interleaved without a clear boundary between the two. A script may automate interactive operations that would otherwise be performed with the keyboard. A script is primarily composed of commands that would otherwise need to be entered at the command line, or in a text editor, the user may use the script to combine some of the commonly used operations into a set of sequences. Many scripts have in fact surpassed the instructions of simple user command sequences, and can also write more complex programs.

Scripts are typically executed by 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. The script can be correctly executed only if the type of the script corresponds to the type of the script execution engine.

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

Commonly used script execution engines can be roughly classified into the following three categories:

one is to compile the script directly into a class file, without a separate script execution engine, and directly use the debugging capability of Java Debug Interface (JDI). The script execution engine comprises script language description, execution and debugging functions. Script execution engines of this type typically include groovy, scala, kotlin, Fantom, Jython, Jruby, and the like. Since such script execution engines do not require a separate engine for debugging, it is outside the scope of the discussion of this application.

The other type is a script execution engine which provides debugging functions and supports actions such as breaking points, stepping and the like when the script execution engine executes the script. Such script execution engines typically include python, perl, PHP, ruby, LUA, ANT, xslt, and so forth. 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 debugging capabilities declared by the authorities to be without debugging capabilities, which typically includes freemarker, BPMN, smooks, gradle, shell, drools, and the like.

Each script engine needs to implement a debugging function, and as can be seen from the above, many script engines do not provide a debugging function at present, so that the scripts cannot be debugged. When such a script is developed, it can be determined whether the script has a problem only by looking at information such as an execution log, an execution result, and the like in the execution environment. After the problem is found, the location in the script where the problem occurred cannot be located directly. At this time, the problem location is usually found by a dichotomy in such a manner that the script is executed again after a part of the script is deleted. Resulting in long development period and low development efficiency.

If the debugging function is directly supported in the script execution engine, the code in the script execution engine needs to be modified, and a long time is usually required. And if the debug function and the run function are executed together, adding the debug function may cause the run function to be problematic. The script execution engine is generally open-source and is more difficult to receive the input of the debugging function with great influence on the function. Therefore, it is necessary to study a method of debugging a script by a script execution engine having no debugging function.

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

Fig. 1 is an architecture schematic 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 number of containers 101 and debuggers 102 is not limited in the embodiments of the present application, and fig. 1 is only described by taking 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 for performing script compilation is disposed in the container 101. Taking a Java container as an example, the Java container may specifically refer to a Java process running a script execution engine. When the Java container is started, relevant parameters of the vulnerability tool can be used for starting the debugging characteristic of the Java virtual machine. The script execution engine in the Java container may refer to a package having script parsing execution capabilities.

A debugging plug-in is deployed in the debugger 102, and the debugger 102 communicates with the container 101 through the debugging plug-in to implement a debugging function for the script.

The interface used for communication between debugger 102 and container 101 may be a debug interface such as JDI. JDI is the interface at the highest level of the three-level modules that Java Platform Debug Architecture (JPDA) includes, defining some debug interfaces needed by the Debugger.

Currently, most JDI debugger implementations are written in the Java language. For example, Java developers are more familiar with Eclipse IDE, Intellij IDEA, which is not the case.

Furthermore, 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, an agent module is deployed in the container 101, and the agent module can implement some judgment operations of the debugger 102 in the related art to reduce the number of interactions between the debugging script process container 101 and the debugger 102. The relevant functions of the agent module will be explained in detail in the following method embodiments, which will not be explained in detail.

Illustratively, taking a Java container as an example, the Java container is deployed on a Java virtual machine. The Java Virtual Machine tool Interface (jvmwood Interface, JVMTI) is a native (native) programming Interface provided by a Java Virtual Machine, and is an updated version of a Java Virtual Machine performance analyzer (JVMPI) and a Java Virtual Machine Debug Interface (JVMDI). From the development history track of the application interface (API), it can be known that JVMTI provides an interface for debugging (debug) and performance analysis (profiler); meanwhile, in Java 5/6, the virtual machine interface also has functions of Monitoring (Monitoring), Thread Analysis (Thread Analysis), Coverage Analysis (Coverage Analysis), and the like. Just because of the powerful function of JVMTI, it is the basis for implementing Java debuggers, as well as other Java runtime testing and analysis tools.

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

Furthermore, the agent module may be compiled into a dynamic link library, and after the agent module is compiled into a dynamic link library, the agent module may be loaded at the time of Java program startup (boot load mode), or may be loaded after Java 5 using runtime (active load mode). So that subsequent containers perform some operations through the proxy module.

It should be noted that the JVMTI is not necessarily implemented in all Java virtual machines, and the implementation of different virtual machines is not the same. However, standard JVMTI implementations are provided in some mainstream virtual machines, such as Sun and IBM, and in some open source, such as Apache Harmony DRLVM.

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

The following explains a script debugging method provided in the embodiments of the present application. Based on the above system architecture, it is known that a part of the debugging function can be performed by the proxy module instead of the debugger in the related art, and thus, some information for debugging needs to be registered in the container in advance. This information includes one or more breakpoints to be debugged, and breakpoint trigger configuration information. The breakpoint trigger configuration information is used to indicate whether a breakpoint satisfies a breakpoint debugging condition. Therefore, when the subsequent container executes the script through the script execution engine, the interaction times with the debugger can be reduced 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 breakpoints and a process of triggering configuration information by the breakpoints, and secondly performing a script debugging process in the script execution process. The following two examples are used to illustrate the two processes, respectively.

Fig. 2 is a flowchart illustrating a script debugging method according to an embodiment of the present application. A detailed explanation is given to the above-described procedure for registering breakpoints and breakpoint trigger configuration information. As shown in fig. 2, the method includes the following steps:

step 201: the container receives a container activation command.

Script debugging is usually triggered by a developer, and a client of the developer is connected with a debugger, so that in one possible implementation, when the client detects a mode-adjusting instruction triggered by the developer through a preset operation, the client sends a script debugging starting request to the debugger. And when the debugger receives the script debugging starting request, starting the locally deployed debugging plug-in, and registering the callback interface through the debugging plug-in so as to enable the debugger to establish communication connection with the container through the callback interface. The debugger then sends a container start instruction to the container, and when the container receives the container start instruction, the agent module and script execution engine may be loaded, via step 202, described below. The above process can be represented by the interaction process between the container and the debugger shown in fig. 3, and will not be described in detail here.

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

In addition, taking a Java container as an example, the communication connection between the debugger and the container may be a socket (socket) connection established between the debugger and the Java container, so as to send a subsequent JDI debugging command.

Step 202: a container loading agent module and a script execution engine.

Based on step 201, the container start instruction also carries configuration information of the agent module, so that the container may initialize the agent module based on the configuration information of the agent module, that is, load the agent module. In the embodiment of the present application, since the determination of the breakpoint debugging condition needs to be performed by the proxy module, as shown in fig. 3, after the proxy module is initialized, a 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 specified breakpoint debugging condition.

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

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

As shown in FIG. 3, an initialization complete message may also be sent to the debugger after the container has loaded the agent module and the script execution engine. After the debugger receives the initialization completion message, one or more breakpoints to be debugged are determined, and breakpoint trigger configuration information is determined. The breakpoint trigger configuration information is used to indicate whether a breakpoint satisfies 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 the breakpoint trigger configuration information.

Alternatively, after the container has loaded the agent module and the script execution engine, the container may not send the initialization completion message to the debugger. In this case, the debugger can start timing when sending the container start instruction, and directly send a breakpoint configuration request to the debugger when the timing duration reaches the reference duration, thereby further reducing the number of interactions between the container and the debugger. The reference time length can be configured by a developer at a development end, and is not 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.

Before the debugger sends the breakpoint configuration request, the one or more breakpoints and breakpoint trigger configuration information need to be determined. In one possible implementation, as shown in fig. 3, the implementation process of the debugger for determining the one or more breakpoints may be: the debugger can determine the 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 can open the script through the debugging plug-in, and then set the key codes, so that the debugger can acquire the one or more key codes.

In a possible implementation manner, the implementation process of the debugger for determining the breakpoint trigger configuration information may be: after the debugger determines the one or more breakpoints, class (class) information corresponding to the key information associated with each breakpoint is obtained in the first mapping table, so that a plurality of key information and class information corresponding to each key information in the plurality of key information are obtained, and each breakpoint is associated with one or more key information in the plurality of key information. In the script, the 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 word in the line code where the breakpoint is located, and the key word may be a servicetaskebeginnnode, a servicetaskennode, and the like.

The first mapping table may be a mapping table between the key information and the class information. Table 1 is a first mapping table provided in this embodiment, and as shown in table 1, the first mapping table includes class information corresponding to each piece of key information. Since different script lines may include the same key information, in order to accurately find the class information corresponding to the key information associated with the breakpoint according to the position 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 corresponds to one local variable, so as to determine whether the breakpoint satisfies the breakpoint debugging 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 may be obtained from a second mapping table, where the second mapping table includes a plurality of key information and a plurality of local variables corresponding to the plurality of key information one to one. Table 2 is a second mapping table provided in the embodiment of the present application. As shown in table 2, each key information may correspond to a local variable. In addition, some key information cannot be directly acquired from the top-level stack, and the key information may be found only in the stacks of other levels. Therefore, the second mapping table also includes a stack number, which is used to indicate the stack at the layer to obtain the key information of the line.

TABLE 2

That is, the breakpoint trigger configuration information includes a plurality of pieces of key information and class information corresponding to each piece of key information in the plurality of pieces 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 key information of the plurality of key information.

It should be noted that the key information, the class information, and the local variables in tables 1 and 2 are described by taking a Java container and a Debug interface as JDI or an interface based on Java Debug Wire Protocol (JDWP) as an example. The container in this embodiment of the application is not limited to a Java container, and may be a container where a script execution engine directly compiled in languages such as C + + is located, at this time, the loading of the proxy module may be implemented in other manners (for example, in manners such as ld _ library and dll injection), and the used debugging interface corresponds to a debugging interface of a system, such as a dbghelp (a debugging trace related module in a windows operating system) of a windows. In this scenario, the class information specifically refers to the name of the assembly derived function, 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 breakpoint trigger configuration information in the proxy module.

Since the breakpoint needs to be discovered by the script execution engine subsequently, and meanwhile, the proxy module needs to determine whether to trigger debugging, after the container receives the breakpoint configuration request, one or more breakpoints may be registered in the script execution engine, and the breakpoint trigger configuration information is registered in the proxy module, so as to facilitate debugging of the script through the embodiment shown in fig. 4 described below.

Through the embodiment shown in fig. 2, the breakpoint trigger configuration information can be registered in the agent module of the container in advance, so that whether the breakpoint satisfies the breakpoint debugging condition is judged by the agent module subsequently, and the judgment by the debugger is not needed, thereby reducing the number of interactions between the debugger and the container, and further improving the efficiency of script debugging.

It should be noted that the above embodiment is described by taking as an example that the breakpoint and the breakpoint trigger configuration information are registered first when the script is debugged, and then the script is debugged by the embodiment shown in fig. 4 described below.

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

Fig. 4 is a flowchart illustrating 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 the breakpoints are registered and the configuration information is triggered by the breakpoints. As shown in fig. 4, the method includes the following steps:

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

In a possible implementation manner, the developer may send a debugging instruction to the container through the debugger, and after the container receives the debugging instruction and completes the registration of the related information shown in fig. 2, the developer may directly start executing the script through the script execution engine.

Optionally, after the container receives the debug instruction and completes the registration of the related information shown in fig. 2, the container may also return a preparation completion message to the debugger. After the debugger receives the preparation completion message, the preparation completion message can be displayed, the 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 is registered by the embodiment shown in fig. 2 before debugging each script of the same type, when the debugger receives the debugging instruction sent by the client, the debugger may directly send the debugging instruction to the container to trigger the container to execute the script by the script execution engine.

Step 402: in the case of execution to any one of the one or more breakpoints by the script execution engine, 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 of the one or more breakpoints can be judged, if so, as shown in fig. 3, the script execution process is suspended, and the agent module is called to detect the breakpoint based on the breakpoint trigger configuration information.

Because the agent module is pre-registered with the breakpoint event callback function, the implementation manner of the container call agent module for detecting the breakpoint based on the breakpoint trigger configuration information may be as follows: and the agent module calls a breakpoint event callback function by taking the breakpoint as a parameter to judge whether the breakpoint meets the breakpoint debugging condition.

As can be seen from the embodiment shown in fig. 2, breakpoint trigger configuration information is also registered in the proxy module, and therefore, the implementation manner for calling the proxy module to detect the breakpoint based on the breakpoint trigger configuration information is specifically as follows: determining class information corresponding to 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; and if the acquired value of the local variable is inconsistent with the value required by the script execution engine to execute the breakpoint, detecting that the breakpoint does not 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 debugging condition. The value required by the script execution engine to execute the breakpoint may be determined by the proxy module according to the location information of the breakpoint in advance, 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 a 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 is not described in detail herein.

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

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

Step 403: and under the condition that the agent module detects that the breakpoint does not 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 debugging condition, the container may continue to execute the script directly through the script execution engine, and the container does not need to interact with the debugger in this scenario.

Correspondingly, when the agent module detects that the breakpoint meets the breakpoint debugging condition, the container sends a debugging trigger instruction to the debugger, so as to instruct the debugger to debug the breakpoint based on the debugging trigger instruction.

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 agent module detects that the breakpoint meets the breakpoint debugging 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 directly continues to restore the script execution engine to continue executing the script without interacting with the debugger.

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 an edit window and focus is placed on a breakpoint line, a call stack is displayed in a stack window, the topmost stack is displayed as a script line, a script execution context is displayed in a local variable window, and so on.

Fig. 5 is a block diagram of a script debugging apparatus 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:

and an executing module 501, configured to execute the script through the script executing engine. The specific implementation process may refer to step 401 in the embodiment of fig. 4.

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

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

Optionally, the apparatus 500 further comprises:

and the sending module is used for sending a debugging trigger instruction to the debugger when the agent module detects that any breakpoint meets 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 start instruction. The specific implementation process may refer to step 201 in the embodiment of fig. 2.

And a loading module 504 for loading the agent module and the script execution engine. The specific implementation process 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. The specific implementation process may refer to step 203 in the embodiment of fig. 2.

And a registering module 505, configured to register one or more breakpoints in the script execution engine, and register breakpoint trigger configuration information in the agent module. The specific implementation process may refer to step 204 in the embodiment of fig. 2.

Optionally, the breakpoint trigger configuration information includes a plurality of pieces of key information and class information corresponding to each piece of key information in the plurality of pieces of key information, and each breakpoint is associated with one or more pieces of key information in the plurality of pieces 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;

obtaining the value of a 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.

Optionally, the detecting 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 agent module and the script execution engine can be deployed in the container in advance, and the breakpoint trigger configuration information is registered, so that whether the breakpoint meets the breakpoint debugging condition is judged by the agent module based on the breakpoint trigger configuration information in the following process, and the judgment through a debugger is not needed, so that the script execution engine which does not support the debugging function can be finally provided with 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 apparatus for triggering an intelligent network service provided in the foregoing embodiment is only illustrated by dividing the functional modules when triggering an intelligent network service, and in practical applications, the function distribution may be completed by different functional modules as needed, 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 apparatus for triggering an intelligent network service and the method for triggering an intelligent network service provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments and are 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 comprises 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 processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present disclosure.

The communication bus 702 may include a path that conveys information between the aforementioned components.

The Memory 703 may be, but is not limited to, a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only Memory (EEPROM), a compact disk read-only Memory (CD-ROM) or other optical disk storage, optical disk storage (including compact disk, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), a 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 coupled to the processor 701 via a communication bus 702. The memory 703 may also be integrated with the processor 701.

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

The communication interface 704 may be any device, such as a transceiver, for communicating with other devices or communication networks, such as an ethernet, a radio access network (radio access network ran), a Wireless Local Area Network (WLAN), etc.

In particular implementations, a computer device may include multiple processors, such as processor 701 and processor 705 shown in FIG. 7, for example, as an embodiment. Each of these processors may be a single-core (single-CPU) processor or 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 a specific implementation, the computer device may be a desktop computer, a laptop computer, a network server, a Personal Digital Assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. The embodiment of the application does not limit the type of the computer equipment.

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 instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is only exemplary of the present application and should not be taken as limiting, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

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

executing a script by the script execution engine;

under the condition that the script execution engine executes any breakpoint in the one or more breakpoints, calling the agent module to detect the any breakpoint based on the breakpoint trigger configuration information;

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.

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

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

3. The method of claim 1, further comprising:

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.

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

the invoking the agent 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;

obtaining 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 the breakpoint does not meet the breakpoint debugging condition.

5. The method according to claim 4, wherein after obtaining the value of the local variable corresponding to 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 the breakpoint meets the breakpoint debugging condition.

6. A script debugging device is characterized in that the script debugging 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; 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 agent module to detect any breakpoint based on the breakpoint trigger configuration information under the condition that the script execution engine executes the breakpoint to any breakpoint in the one or more breakpoints;

the execution module is further configured to continue executing the script through the script execution engine when the agent module detects that the any breakpoint does not satisfy the breakpoint debugging condition.

7. The apparatus of claim 6, further comprising:

and 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 is used for indicating the debugger to debug any breakpoint based on the debugging trigger instruction.

8. The apparatus of claim 6, further comprising:

the receiving module is used for receiving a container starting instruction;

the loading module is used for loading the agent module and the script execution engine;

the receiving module is further configured to receive a breakpoint configuration request sent by a debugger, where the breakpoint configuration request carries the one or more breakpoints and the breakpoint trigger configuration information;

and the registering 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.

9. The apparatus according to any one of claims 6 to 8, wherein the breakpoint trigger configuration information includes a plurality of pieces of key information and class information corresponding to each piece of key information in the plurality of pieces of key information, and each breakpoint is associated with one or more pieces of key information in the plurality of pieces of key information;

the detection module is configured to:

10. The apparatus of claim 9, wherein the detection module is configured to:

11. A script debugging apparatus, comprising 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 of claims 1-5.

12. A computer-readable storage medium having stored therein instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 1-5.