Program debugging method, system and device and storage medium

Abstract

The embodiment of the invention provides a program debugging method, system and device and a storage medium. The method comprises the steps of obtaining a debugging breakpoint; performing breakpoint interception based on the debugging breakpoint to obtain program call stack information; obtaining stack source code information based on the program call stack information; and sending the stack source code information to the user.

Description

Technical Field

[0001] The present invention relates to the field of program development, and in particular to a program debugging method and system. Background Art

[0002] In the current application development of mobile terminals, mini programs have become an increasingly common form of application development. In the development of mini programs, the supporting functions of the mini program are usually encapsulated as an integrated package in the form of a mini program engine software development kit (Software Development Kit, SDK). The integrator (for example, a client developer) integrates the mini program engine SDK into its own application (for example, a mobile client), and then starts the mini program through the application programming interface (Application Programming Interface, API) provided in the mini program engine SDK. The business party (for example, a mini program developer) develops the mini program based on the mini program engine SDK. Therefore, the development of the mini program actually includes the development work of the mini program engine developer, the integrator and the business party. Among them, the mini program engine SDK opens the callback method of the system API for the integrator to carry out secondary development, but during the secondary development process, the system API is difficult to debug. For example, when the client developer is debugging these system APIs or encounters a system crash, he cannot trace the specific source code (for example, JavaScript source code) location of the current mini program code business logic, and can only view the client's own bridge call stack. This makes it impossible to quickly locate the source code location of the error to fix the error (bug). In this case, the usual way to deal with it is that the client developer notifies the front-end developer (i.e., the mini program developer) to add logs in the development tool to simulate the call and re-publish, and the client developer repeatedly debugs to infer the specific source code logic. The debugging process is cumbersome and complicated, and the accuracy rate is not high.

[0003] Therefore, it is hoped that a program debugging method and system can be provided to reduce the difficulty of mini-program development and debugging and improve the debugging quality. Summary of the invention

[0004] One of the embodiments of this specification provides a program debugging method, which includes: obtaining a debugging breakpoint; performing breakpoint interception based on the debugging breakpoint to obtain program call stack information; obtaining stack source code information based on the program call stack information; and sending the stack source code information to a user.

[0005] In some embodiments, the stack source code information may include the target source code at the debugging breakpoint.

[0006] In some embodiments, the program call stack information may be converted into the stack source code information based on a mapping relationship between source code and running code.

[0007] In some embodiments, the breakpoint interception may be performed at an end bridge of the applet engine, the applet engine may be integrated into a client, and the end bridge may be used to connect the client with the applet.

[0008] In some embodiments, the stack source code information may be returned to the client and the applet.

[0009] In some embodiments, the debugging breakpoint can be performed for a synchronous call or an asynchronous call. When the debugging breakpoint is performed for the asynchronous call, the breakpoint interception based on the debugging breakpoint and the acquisition of program call stack information may include: saving temporary program call stack information at the beginning of the asynchronous call; after the breakpoint interception, using the temporary program call stack information as the program call stack information.

[0010] In some embodiments, the stack source code information may include JavaScript source code information.

[0011] One of the embodiments of the present specification provides a program debugging system, including a breakpoint acquisition module, a stack information acquisition module, a stack source code acquisition module and an information sending module; the breakpoint acquisition module is used to acquire debugging breakpoints; the stack information acquisition module is used to perform breakpoint interception based on the debugging breakpoints and acquire program call stack information; the stack source code acquisition module is used to acquire stack source code information based on the program call stack information; the information sending module is used to send the stack source code information to a user.

[0012] One of the embodiments of the present specification provides a program debugging device, including a processor, wherein the processor is used to execute the program debugging method.

[0013] One of the embodiments of the present specification provides a computer-readable storage medium, wherein the storage medium stores computer instructions. When a computer reads the computer instructions in the storage medium, the computer executes the program debugging method. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] This specification will be further described in the form of exemplary embodiments, which will be described in detail by the accompanying drawings. These embodiments are not restrictive, and in these embodiments, the same number represents the same structure, wherein:

[0015] Figure 1 is a schematic diagram of an application scenario of a program debugging system according to some embodiments of this specification;

[0016] Figure 2 is a schematic diagram of a program debugging system according to some embodiments of this specification;

[0017] Figure 3 is a schematic diagram of a program debugging system according to some embodiments of this specification;

[0018] Figure 4 is an exemplary flow chart of a program debugging method according to some embodiments of this specification;

[0019] Figure 5 is a schematic diagram of a program debugging method according to some embodiments of this specification;

[0020] Figure 6 is a schematic diagram of debugging breakpoints according to some embodiments of this specification;

[0021] Figure 7 is a schematic diagram of a program debugging method according to some embodiments of this specification;

[0022] Figure 8a , 8b is a schematic diagram of a program call stack according to some embodiments of this specification;

[0023] Fig. 9 It is a schematic diagram of stack source code according to some embodiments of this specification. DETAILED DESCRIPTION

[0024] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following is a brief introduction to the drawings required for the description of the embodiments. Obviously, the drawings described below are only some examples or embodiments of this specification. For ordinary technicians in this field, this specification can also be applied to other similar scenarios based on these drawings without creative work. Unless it is obvious from the language environment or otherwise explained, the same reference numerals in the figures represent the same structure or operation.

[0025] It should be understood that the "system", "device", "unit" and / or "module" used herein are a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0026] As shown in this specification and claims, unless the context clearly indicates an exception, the words "a", "an", "an" and / or "the" do not refer to the singular and may also include the plural. Generally speaking, the terms "comprise" and "include" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0027] Flowcharts are used in this specification to illustrate the operations performed by the system according to the embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed precisely in order. Instead, the steps may be processed in reverse order or simultaneously. At the same time, other operations may also be added to these processes, or one or more operations may be removed from these processes.

[0028] Figure 1 1 is a schematic diagram of an application scenario of a program debugging system according to some embodiments of this specification. In this specification, the program debugging system 100 is referred to as system 100 for short.

[0029] like Figure 1 As shown, in some embodiments, the system 100 may include an integration end 110 , a service end 120 , a user terminal 130 , a storage device 140 , and a network 150 .

[0030] The integration end 110 and the business end 120 are systems with computing and processing capabilities, and may include various computers, such as servers, personal computers, or computing platforms composed of multiple computers connected in various structures. In some embodiments, the integration end 110 and the business end 120 may be implemented on a cloud platform. For example, a cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, a cross-cloud, a multi-cloud, or a combination of several of them. In some embodiments, the integration end 110 and the business end 120 may be the same device or different devices.

[0031] The integration end 110 and the service end 120 may include one or more sub-processing devices (e.g., single-core processing devices or multi-core multi-core processing devices), and the processing devices may execute program instructions. As examples only, the processing devices may include various common general-purpose central processing units (CPUs), graphics processing units (GPUs), microprocessors, application-specific integrated circuits (ASICs), or other types of integrated circuits.

[0032] The integration terminal 110 can be used by the integrator to develop applications such as clients and the like. The integrator is the developer of client-type applications, and the client applications can include various specific types, such as e-commerce clients, bank clients, online travel clients, social clients, etc. In this specification, the client application may be referred to as the client, which refers to an application used by users and provides users with various services (for example, shopping services, social services, financial services, travel services, etc.), which can run on various operating system platforms such as mobile operating systems (for example, iOS, Android, Hongmeng, etc.), computer operating systems (for example, Windows, Mac OS, Linux, etc.). In some embodiments, the integrator can integrate the mini program engine SDK into the client application through the integration terminal 110 to communicate with the mini program through a bridge. For example, if Figure 2 As shown, the integrator can integrate the mini-program engine SDK 220 into the client application 210 at the integration end 110 through programming, so that the client application 210 can communicate with the mini-program 230 in a bidirectional manner through a bridge. In some embodiments, the integration end 110 can execute the program debugging method as shown in some embodiments of this specification to obtain the stack source code information at the debugging breakpoint and send it to the business end 120. In some embodiments, the integration end 110 can send the client application to the user terminal 130 for user use. In some embodiments, the integration end 110 can exchange information and data with other components in the system 100 (e.g., the business end 120, the user terminal 130, the storage device 140) through the network 150. In some embodiments, the integration end 110 can directly connect to the business end 120 and exchange information and / or data.

[0033] The Mini Program Engine SDK is a software integration package used to connect the Mini Program to the client application. It can be integrated into the platform application through any of the methods such as code integration, static link library, dynamic link library, etc. In this specification, when the Mini Program Engine SDK runs as part of the application, it can be referred to as the Mini Program Engine. For example, Figure 2 As shown, the mini program engine SDK 220 is integrated into the client application 210, and the mini program 230 performs two-way communication with the client application 210 through the mini program engine SDK 220. In some embodiments, the mini program engine SDK may include various components, for example, components that provide basic APIs such as system APIs, components that provide user interface APIs, APIs that provide bridging functions, etc. Figure 2As shown, the mini program engine SDK 220 may include a basic library component 221, a dual engine component 222, and an end bridging component 223. The basic library component 221 may be used to provide an API for external use such as a system API, and is connected to the end bridging component 223 through the bridging part in the basic library component 221. In some embodiments, the basic library component 221 may include an API for front-end development such as JavaScript, which is developed by the person responsible for front-end development. The dual engine component 222 may be used to implement a user interface, including a logic layer and a view layer. The end bridging component 223 may be used for bridging the internal components (e.g., the logic layer and view layer of the dual engine component 222) and the external (e.g., client application 210, mini program 230) of the mini program engine SDK. In some embodiments, the end bridging component 223 may be developed by the person responsible for back-end development. In some embodiments, multiple external components of the mini program engine SDK may be bridged through the end bridging component, for example, the client application 210 may be bridged with the mini program 230 through the end bridging component 223. In this specification, bridging refers to connecting two parties (Party A and Party B) through a third party (Party C).

[0034] The business end 120 can be used for the business party to develop mini-programs. The business party is the developer of mini-programs based on platform applications. Mini-programs can include various types of mini-programs based on platform applications, such as mini-programs that provide government public services, shopping mini-programs, bank client mini-programs, map navigation mini-programs, etc. In some embodiments, the business party can develop mini-programs based on the mini-program engine SDK through the business end 120 to run on the client application developed by the integration end 110. In some embodiments, a mini-program can run on a client application of one or more system platforms (e.g., iOS system, Android system, Hongmeng system, etc.). In some embodiments, mini-programs can be developed in various programming languages ​​and specifications, such as JavaScript, HTML, CSS, Python, PHP, Java, etc.

[0035] The user terminal 130 is used to run client applications and mini-programs. In some embodiments, the user terminal 130 can receive the client application from the integration terminal 110, and then start the mini-program obtained from the service terminal 120 in the client application by means of parameters, etc. In some embodiments, the user terminal 130 can be one of the devices with a processor and capable of running programs, such as a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, a desktop computer 130-4, or any combination thereof.

[0036] The storage device 140 can store data and / or information generated by other devices. In some embodiments, the storage device 140 can store data and / or information generated by the integration end 110 and / or the business end 120, for example, the source code and / or running code (i.e., the generated application code) of the client application and / or the mini-program, etc. In some embodiments, the storage device 140 can store data generated during program debugging, for example, program stack information, etc. In some embodiments, the storage device 140 can also store other data and / or information, for example, the mini-program engine SDK, etc. The storage device 140 may include one or more storage components, each of which may be an independent device or part of another device. The storage device may be local or implemented through the cloud.

[0037] The network 150 can connect the components of the system and / or connect the system with external resources. The network 150 enables communication between the components and with other parts outside the system to facilitate the exchange of data and / or information. In some embodiments, one or more components in the system 100 (e.g., the integration end 110, the business end 120, the user terminal 130, the storage device 140) can send data and / or information to other components via the network 150. In some embodiments, the network 150 can be any one or more of a wired network or a wireless network.

[0038] It should be noted that the above description is provided for illustrative purposes only and is not intended to limit the scope of this specification. For those of ordinary skill in the art, various changes and modifications may be made under the guidance of the contents of this specification. The features, structures, methods and other features of the exemplary embodiments described in this specification may be combined in various ways to obtain additional and / or alternative exemplary embodiments. For example, the storage device 140 may be based on a cloud platform. However, these changes and modifications will not deviate from the scope of this specification.

[0039] Figure 3 It is a schematic diagram of a program debugging system according to some embodiments of the present specification.

[0040] like Figure 3 As shown, the program debugging system 300 may include a breakpoint acquisition module 310, a stack information acquisition module 320, a stack source code acquisition module 330 and an information sending module 340. In some embodiments, each module of the program debugging system 300 may be implemented by the integration terminal 110 through the mini program engine SDK 220.

[0041] In some embodiments, the breakpoint acquisition module 310 may be used to acquire debugging breakpoints.

[0042] In some embodiments, the stack information acquisition module 320 can be used to perform breakpoint interception based on debugging breakpoints to obtain program call stack information.

[0043] In some embodiments, breakpoint interception may be performed at the end bridge of the applet engine, the applet engine may be integrated into the client, and the end bridge may be used to connect the client with the applet.

[0044] In some embodiments, the stack source code acquisition module 330 may be used to acquire stack source code information based on program call stack information.

[0045] In some embodiments, the stack source code information may include target source code at debug breakpoints.

[0046] In some embodiments, the stack source code information may include source code information such as JavaScript.

[0047] In some embodiments, the stack source code acquisition module 330 may convert the program call stack information into stack source code information based on the mapping relationship between the source code and the running code.

[0048] In some embodiments, the information sending module 340 may be used to send the stack source code information to the user.

[0049] In some embodiments, the information sending module 340 may return the stack source code information to the client and the applet.

[0050] In some embodiments, the debugging breakpoint can be performed for synchronous calls or asynchronous calls. When the debugging breakpoint is performed for asynchronous calls, the stack information acquisition module 320 can save temporary program call stack information when the asynchronous call starts; after the breakpoint is intercepted, the temporary program call stack information is used as the program call stack information.

[0051] Figure 4 It is an exemplary flow chart of a program debugging method according to some embodiments of the present specification.

[0052] like Figure 4 As shown, the process 400 includes the following steps. In some embodiments, the process 400 may be executed by the integration terminal 110, specifically, by the integration terminal 110 through the mini program engine SDK (eg, mini program engine SDK 220) integrated in the client.

[0053] Currently, during the development of a mini program, when the mini program is started through the mini program engine SDK integrated by the client, the integrator can perform breakpoint debugging on the system API bridge code in the mini program engine SDK. However, since it is difficult to locate the JavaScript source code of the mini program, the integrator can usually only debug repeatedly through the business party's logs and infer the source code logic of the mini program, resulting in a gap in the debugging process due to the different fields of the parties, making debugging difficult, time-consuming, labor-intensive, and low in accuracy.

[0054] In some embodiments, the above conventional breakpoint debugging process can be as follows: Figure 5 As shown in process 500 in . In some embodiments, in step 510, the integration end 110 can start the mini program and call the mini program API by executing the mini program; in step 520, the mini program API can further call the basic library API in the mini program engine SDK; in step 530, the integration end 110 can perform basic library bridging through the basic library bridging part of the mini program engine SDK (for example, the basic library component 221); in step 540, the integration end 110 can perform end bridging through the end bridging part of the mini program engine SDK (for example, the end bridging component 223), that is, the mini program engine SDK is connected to the client. In some embodiments, when debugging the system API on the client, a call stack (that is, a bridge call stack) is obtained at the end bridging position, and the call stack information does not contain the mini program call stack information (for example, the call stack information of the mini program JavaScript), so it cannot be traced back to the source code. In some embodiments, the information in the bridge call stack can be as follows Figure 6 As shown, the breakpoint is at an API named getSystemInfoSync, which contains a parameter data, but the data does not contain the call stack information of the applet at the breakpoint.

[0055] In some embodiments, the basic library bridging part of the mini-program engine SDK is modified so that it can obtain the context of the current JavaScript call stack when processing the runtime of the system API, and parse the call stack through the mapping relationship between the mini-program source code and the running code (mini-program application) (for example, the index of Sourcemap), and restore it to the JavaScript business source code, and at the same time, the JavaScript business source code is transparently transmitted to the client bridge position through preset parameters. Through the above processing, when the client debugs the system API in the form of breakpoints, it can directly obtain the context of the JavaScript call stack, so as to quickly locate business logic problems. For example, in Figure 5 On the basis of Figure 7 As shown, the mini-program call stack can be obtained between step 750 and step 790, and the call stack information can be passed into the preset parameters.

[0056] Step 410 , obtaining a debugging breakpoint. In some embodiments, step 410 may be performed by the breakpoint obtaining module 310 .

[0057] Debug breakpoints refer to program breakpoints used for program debugging, which can be set manually or automatically by the program developer. In some embodiments, debug breakpoints can be used to debug APIs (e.g., system APIs, etc.) in the mini-program engine SDK. In some embodiments, debug breakpoints can be located in the client source code and set at the system API that calls the mini-program engine SDK, wherein these APIs may include APIs that need to be debugged. In some embodiments, the integration terminal 110 can obtain debug breakpoints from the client source code.

[0058] In some embodiments, the debugging breakpoint can be performed for synchronous calls or asynchronous calls, wherein both synchronous calls and asynchronous calls are for APIs. When the API is a synchronous call, the call stack information of the breakpoint at the API corresponds to the source code that calls the API. When the API is an asynchronous call, the call stack information of the breakpoint at the API usually does not correspond to the source code that calls the API.

[0059] Step 420 , performing breakpoint interception based on the debugging breakpoint, and obtaining program call stack information. In some embodiments, step 420 may be performed by the stack information obtaining module 320 .

[0060] In some embodiments, the integrated end 110 can perform breakpoint interception according to the debugging breakpoint. Specifically, the integrated end 110 can start the applet during the client operation process. When the applet API calls the system API, the debugging breakpoint set therein is triggered and the program operation is temporarily interrupted. In some embodiments, the breakpoint interception can be performed at the end bridge of the applet engine, more specifically, between performing the basic library bridge and performing the end bridge (for example, between step 530 and step 540, between step 750 and step 790). In some embodiments, the applet engine (for example, the applet engine SDK220) can be integrated in the client (for example, the client application 210), and the end bridge (for example, the end bridge component 223) is used to connect the client with the applet (for example, the applet 230).

[0061] Program call stack information refers to the context information when the program is running, which can be expressed as running code. Running code is also called production code, which refers to program code that can be run directly, for example, executable application code, static link library code, dynamic link library code, etc. In some embodiments, the running code may include the code obtained after at least one of the conversion operations such as compiling, compressing, optimizing (for example, removing spaces), and obfuscating the source code. In some embodiments, the program call stack information may include information after the source code is compiled. In some embodiments, after intercepting a debugging breakpoint, the integration terminal 110 can obtain the program call stack information at the breakpoint.

[0062] In some embodiments, the integration terminal 110 can return the program call stack information to the client and / or applet in the form of preset parameters, so that the user can obtain the call stack information at the debugging breakpoint, that is, the context information at the breakpoint. Figure 8a As shown in the figure, the breakpoint is set at the API named getSystemInfoSync. Figure 5 Based on the getSystemInfoSync shown, this API adds a preset parameter jsStack in the parameter data, and passes the obtained program call stack information to jsStack. The client and / or applet can obtain the call stack information at the breakpoint by reading jsStack.

[0063] Since the program call stack information is usually compiled information, that is, the original call stack information, it cannot directly correspond to the source code (for example, the applet source code), and it is still difficult for users to determine the business logic of the source code. Figure 8a In the program call stack information shown in , the top information of the stack is "initSystemInfo@https: / / usr / app / app-service.js:16177:39". Among them, "initSystemInfo" is the method name; "https: / / usr / app / app-service.js" is the file route (i.e., the file path); "16177" is the current line, i.e., the line where the code corresponding to the interruption is located in the code file; "39" is the current line, i.e., the column where the code corresponding to the interruption is located in the code file. Although the top information of the program call stack information includes the calling method name, the file route corresponds to the compiled file app-service.js, so it is impossible to trace back to the source code of the program.

[0064] When the debugging breakpoint is performed on an asynchronous call, the program call stack information obtained during the breakpoint interception is obtained after the API at the breakpoint is executed, and cannot reflect the actual call stack when the API is called. In some embodiments, when the debugging breakpoint is performed on an asynchronous call, the integration end 110 can obtain the program call stack information at that time before the breakpoint interception, that is, when the asynchronous call starts, and save it as temporary program call stack information; after the breakpoint interception, the temporary program call stack information is used as the program call stack information.

[0065] In some embodiments of the present specification, during breakpoint debugging, the context of the current call stack is obtained when processing the system API at the mini-program basic library bridge, and the temporary call stack is saved in advance during asynchronous calls, so as to accurately obtain the call stack at the breakpoint, so that the program logic can be analyzed based on the call stack information, thereby ensuring the quality of debugging. At the same time, there is no need to debug by logging, etc., which reduces the difficulty of debugging and reduces the consumption of manpower and other resources.

[0066] In some embodiments, after step 420 , the integration end 110 may convert the program call stack information into stack source code information by executing step 430 , so that the user can determine the source code at the breakpoint.

[0067] Step 430 , obtaining stack source code information based on the program call stack information. In some embodiments, step 430 may be performed by the stack source code obtaining module 330 .

[0068] The stack source code information refers to the source code information corresponding to the call stack, for example, the source code file path, the location of the source code in the file (the line and column of the file), etc. In some embodiments, the stack source code information may include the target source code at the debugging breakpoint, wherein the target source code may include the method name called at the debugging breakpoint, the file route of the method source code, the location of the method source code in the code file (the line and column), etc.

[0069] In some embodiments, the stack source code information may include source code information of various programming languages, for example, at least one of source code information of JavaScript, HTML, CSS, Python, PHP, Java, etc.

[0070] In some embodiments, the integration terminal 110 can convert the program call stack information into stack source code information based on the mapping relationship between the source code and the running code. The mapping relationship may include the corresponding position relationship between the source code and the running code before and after the code conversion, that is, the source code position before the conversion corresponding to the converted code, such as Sourcemap. In some embodiments, the integration terminal 110 can also obtain the stack source code information from the program call stack information in other ways, such as by decompiling.

[0071] The following Figure 8a and 8b Take the example to illustrate the program call stack information and stack source code information before and after the conversion. Figure 8a This is the program call stack information before conversion. Figure 8b The converted stack source code information.

[0072] In some embodiments, the integration terminal 110 can split important information in the program call stack information by regular expression matching and other methods to obtain information such as method name, file route, current line of executable file, current column of executable file, etc. Figure 8a Taking "initSystemInfo@https: / / usr / app / app-service.js:16177:39" in the example, after splitting, the method name "initSystemInfo", the file route "https: / / usr / app / app-service.js", the current line "16177" of the executable file, and the current column "39" of the executable file are obtained.

[0073] In some embodiments, the integration terminal 110 can pass the current row and column data of the executable file through the Sourcemap index of the applet, and reversely parse to obtain the target source code file route, target code line, and target code column. In some embodiments, the integration terminal 110 can also reassemble the call stack information through the at method name (target code file route: target code line: target code column). Figure 8a Taking "initSystemInfo@https: / / usr / app / app-service.js:16177:39" in the applet as an example, through the applet Sourcemap index, the file route "https: / / usr / app / app-service.js", the current line "16177" of the executable file, and the current column "39" of the executable file can be reverse parsed to obtain the target source code file route " / src / pages / demo / demo-component.mpx", the target code line "40" and the target code column "0", and then the call stack information is reassembled through the at method name (target code file route: target code line: target code column) to obtain Figure 8bAs shown in the figure, "at initSystemInfo( / src / pages / demo / demo-component.mpx:40:0)". From this, we can get the source code corresponding to the breakpoint, which is located at the 40th line and 0th column of the applet source code file "demo-component.mpx" with the path " / src / pages / demo / demo-component.mpx". The source code can be as follows Fig. 9 As shown, it can be seen that the method "getSystemInfoSync" is called here.

[0074] Step 440 , sending the stack source code information to the user. In some embodiments, step 440 may be performed by the information sending module 340 .

[0075] In some embodiments, the integration terminal 110 can send the acquired stack source code information to the user. Among them, the user can include at least one of the integrator, the business party, etc. In some embodiments, the integration terminal 110 can return the stack source code information to at least one of the client and the mini program. In some embodiments, the integrator and / or the business party can judge the mini program code logic through the stack source code information to fix errors, for example, illegal incoming parameters, wrong calls, etc. In some embodiments, the user can include the mini program engine SDK developer, and the integration terminal 110 can return the stack source code information to the mini program engine SDK developer so that it can fix errors in the mini program engine SDK based on the stack source code information.

[0076] In some embodiments, the integration end 110 may return the acquired stack source code information to the client etc. in various ways, for example, by calling back preset parameters in an API, by calling other APIs, etc.

[0077] In some embodiments, the integration terminal 110 can add preset parameters to the system API through the callback of the system API, write the stack source code information into the preset parameters, and return the stack source code information through the preset parameters. Figure 8a and 8b As shown, in Figure 6 Based on the original parameters of the API named getSystemInfoSync, a new preset parameter jsStack is added. This API is the API at the debugging breakpoint. Figure 8b As shown, the stack source code information is written into jsStack, and the client can obtain the stack source code information by reading the content in jsStack.

[0078] In some embodiments, the integration end 110 may return the acquired stack source code information to the client in other ways, for example, by sending the stack source code information to the client by calling other APIs, where the other APIs are different from the system APIs at the breakpoint.

[0079] In some embodiments of the present specification, by converting the program call stack information (i.e., the original call stack information) obtained at the breakpoint into stack source code information directly corresponding to the mini-program source code, program developers such as integrators and business parties can locate the mini-program source code logic based on the stack source code information, and thus perform operations such as error repair on the code based on the code logic, thereby greatly improving the quality of program debugging and reducing the difficulty of debugging; at the same time, it solves the problem that when the mini-program engine program SDK is debugging the system API, the client cannot quickly locate the mini-program code business logic due to different fields.

[0080] Figure 7 It is a schematic diagram of a program debugging method according to some embodiments of this specification.

[0081] like Figure 7 As shown, process 700 may include the following steps. In some embodiments, process 700 may be executed by integration terminal 110, specifically, by integration terminal 110 through a small program engine SDK (e.g., small program engine SDK 220) integrated in the client. In some embodiments, integration terminal 110 may implement the program debugging method shown in steps 420 and 430 by executing the steps shown in process 700. In some embodiments, process 700 may be implemented on the basis of process 500.

[0082] Step 710, call the mini program API.

[0083] In some embodiments, the integration end 110 can run the client and start the mini-program in the client through parameters and the like. The integration end 110 can call the mini-program API by running the mini-program.

[0084] Step 720, calling the basic library API.

[0085] In some embodiments, the mini-program API may be implemented through a basic library API, and the integration terminal 110 may further call the basic library API by calling the mini-program API, wherein the basic library API may include a system API.

[0086] Step 730, determine whether it is an asynchronous API.

[0087] In some embodiments, the integration terminal 110 may determine whether the called basic library API is an asynchronous API. If it is an asynchronous API, steps 740 and 750 are executed in sequence, otherwise step 750 is executed directly.

[0088] Step 740, obtain the mini-program call stack information in advance, and parse to obtain the stack source code information.

[0089] Since a small program is running here, the small program call stack here is the program call stack. In some embodiments, if the basic library API called is determined to be an asynchronous API, the integration terminal 110 can obtain the small program call stack information in advance (i.e., save the program call stack information before the breakpoint interception), and save it as temporary program call stack information, and then parse the temporary call stack information to obtain the stack source code information. For more information on how to obtain the program call stack and stack source code information, please refer to the relevant description of steps 420 and 430, which will not be repeated here.

[0090] In some embodiments, when executing step 740, the integration end 110 can directly execute step 750 after obtaining the temporary program call stack information, that is, omit the operation of parsing to obtain the stack source code information, and then execute step 775 between step 760 and step 780 to parse the mini program call stack information into call stack source code information.

[0091] Step 750, perform basic library bridging.

[0092] In some embodiments, if it is determined that the called basic library API is a synchronous API, or after executing step 740, the integration end 110 can perform basic library bridging through the basic library bridging part (e.g., basic library component 221) in the mini-program engine SDK. In some embodiments, the integration end 110 can perform breakpoint interception at the basic library bridging to suspend the program, and obtain the program call stack information through subsequent steps.

[0093] Step 760, determine whether the mini-program call stack information is included.

[0094] In some embodiments, the integration terminal 110 may determine whether the currently saved information already contains the mini-program call stack information.

[0095] When the parsing operation is not performed in step 740, the applet call stack information here is the applet call stack information before parsing. If the judgment result is that the currently saved information already contains the applet call stack information, after step 760, the applet call stack information can be parsed into call stack source code information by executing step 775, and then step 780 is executed.

[0096] When the parsing operation has been performed in step 740 , the mini-program call stack information here is the parsed stack source code information. If the judgment result is that the currently saved information already contains the mini-program call stack information, step 780 can be directly executed after step 760 .

[0097] If the judgment result is that the currently saved information does not include the mini-program call stack information, step 770 is executed after step 760 to obtain the mini-program call stack information.

[0098] Step 770, obtain the mini-program call stack information and parse the stack source code information. This step is similar to step 740 and will not be repeated here.

[0099] Step 780, passing the stack source code information into the preset parameters.

[0100] In some embodiments, the integration terminal 110 can pass the stack source code information into the preset parameters of the API at the debugging breakpoint to return the stack source code information to the client and / or the applet. The preset parameters may include parameters newly added based on the original parameters of the API, for example, Figure 8a and 8b The parameter jsStack in the API named getSystemInfoSync in the example. For more information about how to return the stack source code information to the client and / or applet, please refer to the relevant description of step 440, which will not be repeated here.

[0101] Step 790, perform end bridging.

[0102] In some embodiments, the integration end 110 can perform end bridging through the end bridging part of the mini program engine SDK (e.g., the end bridging component 223), so that the client can obtain the API information at the breakpoint through the end bridging, and read the preset parameters of the API, thereby obtaining the stack source code information. In some embodiments, after obtaining the stack source code information, the integration party and / or the business party can analyze the mini program source code according to the stack source code information to repair code errors.

[0103] It should be noted that the above description of processes 400, 500 and 700 is only for example and explanation, and does not limit the scope of application of this specification. For those skilled in the art, various modifications and changes can be made to processes 400, 500 and 700 under the guidance of this specification. However, these modifications and changes are still within the scope of this specification. For example, steps 730, 760 and 770 can be omitted, that is, regardless of asynchronous call or synchronous call, the program call stack information is saved in advance before the breakpoint interception and parsed into stack source code information, and then the stack source code information is directly written into the preset parameters at the breakpoint interception, that is, step 740 is directly executed after step 720, and step 780 is directly executed after step 750.

[0104] The beneficial effects that may be brought about by the embodiments of this specification include but are not limited to: (1) When debugging on the client side, by obtaining the current program call stack information (i.e., context information) of the system API at the breakpoint at the basic library bridge of the mini-program engine SDK, and converting it into stack source code information based on the mapping relationship between the source code and the running code (for example, the index of Sourcemap), and returning it to the client through preset parameters, it is possible to directly obtain the call stack information that can directly correspond to the mini-program, quickly locate business logic problems, improve debugging efficiency, reduce debugging difficulty, save manpower and other resources, and also improve debugging quality; (2) When making asynchronous calls, save the program call stack in advance, so that accurate call stack information can be obtained in any case, with good adaptability and further ensuring the quality of debugging. It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects that may be produced may be any one or a combination of the above, or any other beneficial effects that may be obtained.

[0105] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only for example and does not constitute a limitation of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and corrections to this specification. Such modifications, improvements and corrections are suggested in this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

[0106] At the same time, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and / or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "one embodiment" or "an embodiment" or "an alternative embodiment" mentioned twice or more in different positions in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures or characteristics in one or more embodiments of this specification can be appropriately combined.

[0107] In addition, unless explicitly stated in the claims, the order of the processing elements and sequences described in this specification, the use of alphanumeric characters, or the use of other names are not intended to limit the order of the processes and methods of this specification. Although the above disclosure discusses some invention embodiments that are currently considered useful through various examples, it should be understood that such details are only for illustrative purposes, and the attached claims are not limited to the disclosed embodiments. On the contrary, the claims are intended to cover all modifications and equivalent combinations that are consistent with the essence and scope of the embodiments of this specification. For example, although the system components described above can be implemented by hardware devices, they can also be implemented only by software solutions, such as installing the described system on an existing server or mobile device.

[0108] Similarly, it should be noted that in order to simplify the description disclosed in this specification and thus help understand one or more embodiments of the invention, in the above description of the embodiments of this specification, multiple features are sometimes combined into one embodiment, figure or description thereof. However, this disclosure method does not mean that the features required by the subject matter of this specification are more than the features mentioned in the claims. In fact, the features of the embodiments are less than all the features of the single embodiment disclosed above.

[0109] In some embodiments, numbers describing the number of components and attributes are used. It should be understood that such numbers used in the description of the embodiments are modified by the modifiers "about", "approximately" or "substantially" in some examples. Unless otherwise specified, "about", "approximately" or "substantially" indicate that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may change according to the required features of individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and adopt the general method of retaining digits. Although the numerical domains and parameters used to confirm the breadth of their range in some embodiments of this specification are approximate values, in specific embodiments, the setting of such numerical values ​​is as accurate as possible within the feasible range.

[0110] Each patent, patent application, patent application publication, and other materials, such as articles, books, specifications, publications, documents, etc., cited in this specification are hereby incorporated by reference in their entirety. Except for application history documents that are inconsistent with or conflicting with the contents of this specification, documents that limit the broadest scope of the claims of this specification (currently or later attached to this specification) are also excluded. It should be noted that if the descriptions, definitions, and / or use of terms in the materials attached to this specification are inconsistent or conflicting with the contents described in this specification, the descriptions, definitions, and / or use of terms in this specification shall prevail.

[0111] Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other variations may also fall within the scope of this specification. Therefore, as an example and not a limitation, alternative configurations of the embodiments of this specification may be considered consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims

1. A program debugging method, comprising: Get debug breakpoints; Perform breakpoint interception based on the debugging breakpoint to obtain program call stack information; Acquiring stack source code information based on the program call stack information; The stack source code information is sent to the user. 2 . The method according to claim 1 , wherein the stack source code information includes the target source code at the debugging breakpoint.

3. The method according to claim 1, wherein obtaining stack source code information based on the program call stack comprises: Based on the mapping relationship between the source code and the running code, the program call stack information is converted into the stack source code information.

4. According to the method of claim 1, the breakpoint interception is performed at the end bridge of the mini-program engine, the mini-program engine is integrated in the client, and the end bridge is used to connect the client and the mini-program.

5. The method according to claim 4, wherein returning the stack source code information to the user comprises: The stack source code information is returned to the client and the applet.

6. The method according to claim 1, wherein the debugging breakpoint is performed for a synchronous call or an asynchronous call, and when the debugging breakpoint is performed for the asynchronous call, the step of performing breakpoint interception based on the debugging breakpoint to obtain program call stack information comprises: When the asynchronous call starts, saving temporary program call stack information; After the breakpoint interception is performed, the temporary program call stack information is used as the program call stack information.

7. The method of claim 1, wherein the stack source code information comprises JavaScript source code information.

8. A program debugging system, comprising a breakpoint acquisition module, a stack information acquisition module, a stack source code acquisition module and an information sending module; The breakpoint acquisition module is used to acquire debugging breakpoints; The stack information acquisition module is used to perform breakpoint interception based on the debugging breakpoint and acquire program call stack information; The stack source code acquisition module is used to acquire stack source code information based on the program call stack information; The information sending module is used to send the stack source code information to the user.

9. A program debugging device, comprising a processor, wherein the processor is configured to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, wherein the storage medium stores computer instructions. When a computer reads the computer instructions in the storage medium, the computer executes the method according to any one of claims 1 to 7.

Images