Troubleshooting method and device for application program

Abstract

The present specification provides a troubleshooting method and device of an application program, wherein the troubleshooting method of the application program comprises: recording a calling parameter on a data transmission channel in a case where a target application program is started, wherein the code of the target application program comprises a first type of code and a second type of code, and the data transmission channel is used to realize function calling between the first type of code and the second type of code in the target application program; if a fault report instruction of the target application program is detected, historical recording information corresponding to the target application program is acquired; and the code of the target application program is executed according to a historical calling parameter in the historical recording information, and execution data of the target application program is played back, wherein the played-back execution data is used to determine a fault cause of the target application program. The historical calling parameter recorded in a previous running process is directly used to re-execute the code, play back the running condition of the target application program, and accurately and efficiently locate the fault cause.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method for troubleshooting application problems. This specification also relates to an application troubleshooting apparatus, a computing device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of computer technology, more and more applications have emerged. Due to factors such as network environment, configuration selection, user standards, and testing limitations, failures inevitably occur during the operation of these applications, leading to numerous online problems. Therefore, it is necessary to troubleshoot these application failures in a timely manner.

[0003] In existing technologies, when users encounter malfunctions while using an application, they typically describe their operation and the malfunction in detail, submit a malfunction report, and then staff will troubleshoot the malfunction based on the user's description. Alternatively, staff can anticipate the information needed for debugging and embed logs into the application's code, so that when a user reports a malfunction, the malfunction can be troubleshooted by analyzing the logs.

[0004] However, in the methods described above, it is difficult for users to clearly describe the operations they performed and the specific faults that occurred, and it is also difficult for staff to troubleshoot specific faults based on vague descriptions. In addition, embedding a large number of logs in the code will slow down the application's response speed, and the massive amount of logs is difficult to save, making it difficult to accurately and quickly locate the exact fault. The accuracy and efficiency of application fault diagnosis are low. Therefore, there is an urgent need to provide an accurate and efficient operation or process for diagnosing application faults. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a method for troubleshooting application problems. This specification also relates to an application troubleshooting apparatus, a computing device, and a computer-readable storage medium, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a method for troubleshooting an application is provided, comprising:

[0007] When the target application is started, the call parameters on the data transmission channel are recorded. The code of the target application includes first type code and second type code. The data transmission channel is used to implement function calls between the first type code and the second type code in the target application.

[0008] If a fault reporting command is detected from the target application, the historical recording information corresponding to the target application is obtained.

[0009] Based on the historical call parameters in the historical recording information, the code of the target application is executed, and the execution data of the target application is replayed. The replayed execution data is used to determine the cause of the target application's failure.

[0010] According to a second aspect of the embodiments of this specification, an application troubleshooting apparatus is provided, comprising:

[0011] The recording module is configured to record the call parameters on the data transmission channel when the target application is started. The code of the target application includes first type code and second type code. The data transmission channel is used to implement function calls between the first type code and the second type code in the target application.

[0012] The acquisition module is configured to acquire historical recording information corresponding to the target application if a fault reporting command of the target application is detected.

[0013] The playback module is configured to execute the code of the target application based on the historical call parameters in the historical recording information, and to replay the execution data of the target application. The replayed execution data is used to determine the cause of the failure of the target application.

[0014] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0015] Memory and processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the steps of the above-described troubleshooting method for application programs.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the above-described troubleshooting method for an application.

[0018] The troubleshooting method for an application provided in this specification involves recording call parameters on a data transmission channel when the target application is started. The code of the target application includes a first type of code and a second type of code. The data transmission channel is used to implement function calls between the first type of code and the second type of code in the target application. If a fault report instruction of the target application is detected, the historical recording information corresponding to the target application is obtained. Based on the historical call parameters in the historical recording information, the code of the target application is executed, and the execution data of the target application is replayed. The replayed execution data is used to determine the cause of the fault in the target application.

[0019] In this scenario, during the execution of the target application, the call parameters on the data transmission channel between the first and second types of code within the target application can be recorded. These call parameters reflect the operations performed by the user within the target application. Therefore, when the target application malfunctions, the code can be re-executed based on the historical call parameters recorded during previous execution, replaying the target application's execution data. This replay process reproduces the target application's running screen, eliminating the need to record the target application's running screen. By combining the target application's execution data with the reproduced running screen, staff can determine the cause of the target application's malfunction, improving the accuracy and efficiency of troubleshooting. Attached Figure Description

[0020] Figure 1 This is a flowchart of a troubleshooting method for an application provided in one embodiment of this specification;

[0021] Figure 2a This is a schematic diagram of a data transmission channel between WebAssembly and JavaScript provided in one embodiment of this specification;

[0022] Figure 2b This is a flowchart illustrating the recording process of calling parameters according to one embodiment of this specification;

[0023] Figure 2c This description is a schematic diagram of the traversal process of calling parameters in historical recording information provided in the first embodiment;

[0024] Figure 3 This is a flowchart illustrating a troubleshooting method for an application in a browser scenario, provided by an embodiment of this specification.

[0025] Figure 4 This is a schematic diagram of the structure of an application troubleshooting device provided in one embodiment of this specification;

[0026] Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0027] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0028] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0029] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0030] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0031] WebAssembly (WASM) is a virtual instruction set architecture. Its overall architecture includes the core ISA definition, binary encoding, program semantics definition and execution, and application programming interfaces (WebAssemblyAPI) for different embedded environments (such as the Web). Its initial goal was to compile programs written in languages ​​like C / C++ to run on the Web platform with security and near-native application speeds. WebAssembly is a new type of code that runs in modern web browsers, offering new performance features and effects. It was not designed for hand-written code, but rather to provide an efficient compilation target for low-level source languages ​​such as C, C++, and Rust.

[0032] JavaScript (JS) is a high-level, multi-paradigm, interpreted programming language. It is a prototype-based, function-first language that supports object-oriented, imperative, and functional programming. It provides syntax for manipulating text, arrays, dates, and regular expressions. While it does not support I / O (such as network, storage, and graphics), this can be supported by its host environment. The language has been standardized and is used by the vast majority of websites worldwide, and is supported by major browsers globally.

[0033] C (hereafter referred to as C) is a procedural, abstract, general-purpose programming language widely used in low-level development. C is highly favored in programming due to its efficiency, flexibility, rich functionality, strong expressiveness, and high portability. C compilers are commonly found on various operating systems.

[0034] It should be noted that due to factors such as network environment, configuration selection, user standards, and testing limitations, failures are inevitable during the operation of the application, leading to numerous online problems. Therefore, it is necessary to promptly investigate and resolve any failures in the application.

[0035] In practice, complex applications written using WebAssembly need to handle complex inputs and internal states. When a user reports a fault to staff, it's difficult to clearly describe the actions they performed, and staff also struggle to reconstruct the application's internal state at the time of the fault based on vague descriptions. Often, to avoid difficulty in locating the fault, staff need to anticipate the information needed for debugging and embed logs in the code. However, a large number of logs slows down the application's response time to user input, and storing massive amounts of logs on the user's terminal is also difficult.

[0036] One possible implementation is to replace handwritten logs with recorded user input. For example, rrweb (a basic library for recording and replaying web pages, which can save the DOM and user actions as serializable data for remote playback) records the user's keyboard and mouse input, as well as the output to the browser, i.e., HTML / DOM updates. This input / output recording can be viewed by staff, is smaller in size than video recordings, and provides more information to staff.

[0037] However, there's no fundamental difference between watching rrweb playback and watching recorded video; staff can only observe surface phenomena and cannot observe the application's internal state variables. Furthermore, recording HTML / DOM data involves a significant amount of data. Moreover, other outputs, such as Canvas / WebGL rendering, often don't get recorded due to their larger data volume compared to HTML / DOM, or the recording sampling rate or resolution is reduced for cost reasons.

[0038] Therefore, this specification provides a troubleshooting solution for applications, enabling low-cost, 24 / 7 full I / O (Input / Output) recording. Users can attach I / O recording files when reporting faults. Staff can execute the code corresponding to the application version to replay the I / O recording files, reconstruct the application's internal state, and pinpoint the cause of the fault.

[0039] This specification provides a method for troubleshooting application problems. It also relates to an application troubleshooting device, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0040] Figure 1 A flowchart illustrating a troubleshooting method for an application according to an embodiment of this specification is shown. This method is applied to an application management platform, which allows users to run the application and also allows staff to re-execute the application code, replay recorded call parameters, and locate the cause of the fault. The application management platform can be a client, server, or webpage, and specifically includes the following steps 102-106:

[0041] Step 102: When the target application is started, record the call parameters on the data transmission channel. The code of the target application includes first type code and second type code. The data transmission channel is used to implement function calls between the first type code and the second type code in the target application.

[0042] Specifically, the target application is the application currently used by the user. This target application is the application corresponding to the WebAssembly code environment, such as a browser application. WebAssembly has clear I / O boundaries, which makes it easy to record the full I / O parameters of the target application. Therefore, when a fault is reported, the code of the target application can be executed by recording the I / O parameters, so as to accurately and efficiently replay and locate the cause of the fault.

[0043] It's important to note that the data transmission channel is the communication channel for function calls between the first type of code and the second type of code in the target application. The first type of code is WebAssembly, and the second type of code is JavaScript. In other words, the target application includes both WebAssembly and JavaScript code. Since WebAssembly in the target application lacks the ability to obtain user input / output, input / output parameters must be obtained from the JavaScript side. WebAssembly relies on JavaScript to provide input / output parameters. The WebAssembly standard is a relatively weak communication method; it can only pass simple types of values, such as int values, when calling a function, and cannot pass complex structures, such as user-entered usernames and passwords. Therefore, a unified data transmission channel is pre-configured between WebAssembly and JavaScript. During the target application's execution, function calls between WebAssembly and JavaScript can be achieved through this standardized data transmission channel, allowing WebAssembly to support the passing of complex types as parameters and return values.

[0044] In practical applications, a standardized data transmission channel can be pre-configured between WebAssembly and JavaScript in the application, thus unifying the communication channel between WebAssembly and JavaScript in the target application. During the execution of the target application, user operations are implemented through function calls between WebAssembly and JavaScript. These function calls require passing through the pre-configured data transmission channel. Recording the call parameters on this data transmission channel involves recording information related to the user's operations within the target application, i.e., recording the target application's input / output parameters.

[0045] In one optional implementation of this embodiment, the data transmission channel between WebAssembly and JavaScript can be pre-defined, that is, the data transmission channel between the first type of code and the second type of code in the target application can be configured as follows:

[0046] Modify the location in the target application's code where the first type of code calls the second type of code to call the first function;

[0047] Modify the location in the target application's code where the second type of code calls the first type of code to call the second function;

[0048] Among them, the first function and the second function are pre-encapsulated functions used to record the call parameters of the function call process.

[0049] In practical applications, the WebAssembly specification and JavaScript engine implementations of the WebAssembly specification support both WebAssembly calling JavaScript functions and JavaScript calling WebAssembly functions. The following is a code example in C language using the Emscripten compiler to demonstrate how WebAssembly can call JavaScript:

[0050]

[0051] `window.alert` is a JavaScript function. `alert` is a scripting language used in HTML / DOM, meaning "reminder." It's a common method of the `window` object in JavaScript, primarily used to display dialog boxes after defining and executing certain functions. Alert dialog boxes are typically used to provide user notifications. Therefore, `window.alert`'s function is to display a dialog box in an application. C++ doesn't have a built-in `window` object or a `window.alert` function. To enable dialog boxes in C, the JavaScript `window.alert` function needs to be wrapped into a function that C can call. Therefore, a `call_alert` function is created and provided to C via `EM_JS`. In other words, `call_alert` is a window function that C can call. In other words, `EM_JS` is code that encapsulates the code that can record function call parameters.

[0052] It should be noted that the above example illustrates the functionality of a pop-up dialog box, specifically wrapping the JavaScript `window.alert` function into a C-callable `call_alert` function. In practice, when C needs user-interaction-related functions but lacks a corresponding function, JavaScript functions can be encapsulated into C-callable functions and provided to C via `EM_JS`. In other words, a unified `JsCall` mechanism can be implemented, unifying the data transmission channel between WebAssembly and JavaScript to achieve the serialization of complex data structures. WebAssembly needs to serialize the input complex structure to obtain a binary array, which is then passed to JavaScript for deserialization.

[0053] In practice, this unified JsCall mechanism provides a single, unified function for adding recorded code, and supports passing complex types as parameters and return values. Specifically, EM_JS can be implemented as follows:

[0054] EM_JS(const char*,js_call,(JsCallCode method,const char*argPtr),{

[0055] return window.jsCall(method,argPtr>>>0);

[0056] })

[0057] In JsCall, JsCallCode is an enumerated constant used to identify the encapsulated function, thereby distinguishing which function the current JsCall is calling. It serves as the array index of the corresponding call parameters, essentially acting as the identifier of the encapsulated function. Each time a new encapsulated function is added, that is, each time a new JsCall is added, a new constant definition is required.

[0058] In practical applications, when calling a function, it can be determined whether the function's `method` exists in the `methodCode` of the enumerated constant `JsCallCode`. If it exists, the corresponding function can be found; otherwise, an error is thrown, indicating that the corresponding function has not been previously encapsulated. For example, in addition to the `call_alert` function obtained by encapsulating the `window.alert` function for the pop-up dialog box, a corresponding C-callable function 2 can also be obtained by encapsulating the function for displaying the shopping cart. In this case, `methodCode` includes two enumerated constants, such as 1 and 2, where 1 identifies the `call_alert` function and 2 identifies function 2.

[0059] Additionally, `argPtr` is a binary parameter obtained by serializing a complex structure, such as user input or an operation to be performed. For example, the complex structure could be the user's username and password, meaning `argPtr` represents the user input to be recorded. `window.jsCall` is a function written in JavaScript, and its return type is also binary serialized. Its purpose is to enable global access to the `window` object, similar to a global variable, allowing access to functions.

[0060] The following is a partial code example of the target application:

[0061]

[0062]

[0063] In practical applications, by modifying all WebAssembly calls to JavaScript to call `js_call`, all call parameters can be recorded on `window.jsCall`. This `js_call` is the first function, which uses a C method to implement the call to the JavaScript function. In other words, it defines a specification for WebAssembly calls to JavaScript, allowing the recording of all call parameters.

[0064] Additionally, JavaScript calls WebAssembly, compiled with Emscripten and written in C. An example code snippet is shown below:

[0065] void EMSCRIPTEN_KEEPALIVE my_function(){

[0066] printf("I am being kept alive\n");

[0067] }

[0068] / / On the JavaScript side, enable loadedModule.my_function() to call functions exported from C.

[0069] It should be noted that, based on EMSCRIPTEN_KEEPALIVE, similar to EM_JS mentioned above, a unified WasmCall mechanism can also be encapsulated, as shown in the following code example:

[0070]

[0071] WasmCallCode, similar to JsCallCode, is also a predefined enumeration constant. A separate wasmCall function can be wrapped in JavaScript for recording. A code example of the wasmCall function is as follows:

[0072]

[0073] In practical applications, by rewriting the JavaScript call to WebAssembly and calling wasmCall, the various call parameters can be recorded. This wasmCall is the second function. In other words, it defines a specification for JavaScript to call WebAssembly, and through this specification, the various call parameters of JavaScript to WebAssembly can be recorded.

[0074] It's important to note that by modifying the call locations in the target application's code—from WebAssembly calling JavaScript to `js_call`, and from JavaScript calling WebAssembly to `wasmCall`—the entry point for communication between WebAssembly and JavaScript is unified. WebAssembly calls JavaScript via `jsCall`, and JavaScript calls WebAssembly via `wasmCall`, thus enabling the recording of relevant call parameters between WebAssembly and JavaScript. This establishes a standardized data transmission channel between WebAssembly and JavaScript. Recording the call parameters on this channel provides a unified serialization format and recording standard. Recording eliminates the need to serialize the application's state into persistent byte arrays; only call parameters need to be recorded. This results in a smaller data volume compared to recording HTML / DOM data, significantly reducing memory and CPU (Central Processing Unit) overhead caused by serialization.

[0075] Example, Figure 2a This is a schematic diagram of a data transmission channel between WebAssembly and JavaScript provided in one embodiment of this specification, as shown below. Figure 2aAs shown, the `js_call` function encapsulated in WebAssembly can call the `JsCall` function in JavaScript. This `JsCall` function can include `js function 1`, `js function ...`, and `js function n`, such as the `window.alert` function being a `js` function. Similarly, the `WasmCall` function encapsulated in JavaScript can call the `wasm_call` function in WebAssembly. This `wasm_call` function can include `C function 1`, `C function ...`, and `C function n`.

[0076] In one optional implementation of this embodiment, after unifying the data transmission channel between WebAssembly and JavaScript, the call parameters on the data transmission channel can be recorded during the execution of the target application, thereby recording the operation information performed by the user in the target application. The specific implementation process for recording the call parameters on the data transmission channel is as follows:

[0077] The first function records the first call parameter of the first type of code calling the second type of code, and the second function records the second call parameter of the second type of code calling the first type of code.

[0078] In practice, the first function refers to the js_call function, and the second function refers to the wasmCall function.

[0079] It should be noted that by modifying the call location of WebAssembly calling JavaScript in the target application's code to call js_call, and the call location of JavaScript calling WebAssembly to call wasmCall, the communication entry point between WebAssembly and JavaScript can be unified. During the execution of the target application, WebAssembly calls JavaScript through the first function js_call, and JavaScript calls WebAssembly through the second function wasmCall. Therefore, the first function can record the first call parameter of the first type of code calling the second type of code, and the second function can record the second call parameter of the second type of code calling the first type of code. The recorded call parameters are the operation information performed by the user in the target application. Subsequently, when the target application fails, only the recorded call parameters need to be replayed to re-execute the code in the same runtime environment as the online application, reproduce the user's operation, and accurately and efficiently locate the fault.

[0080] In one optional implementation of this embodiment, the first calling parameter of the second type of code is recorded through the first function. The specific implementation process can be as follows:

[0081] Obtain the first input information and serialize it to obtain the corresponding first function parameters;

[0082] Execute the first function based on the first function parameters, obtain and record the return value of the first function.

[0083] Specifically, the first input information refers to the information entered by the user in the target application to call functions in JavaScript, such as the user's username and password. The return value refers to the user's input information returned by JavaScript after executing the first function. For example, if WebAssembly asks JavaScript what the user just entered, JavaScript returns the username and password entered by the user; this username and password is the return value.

[0084] It should be noted that for WebAssembly, the input / output that is valuable for recording is the return value of the first function (js_Call). The function parameters of the first function (js_Call) are generated by executing the WebAssembly code, which can be reproduced during playback by executing the WebAssembly code without recording. Therefore, it is sufficient to record the return value of the first function during the call of the first function.

[0085] In addition, to achieve full recording of Input / Output, it is necessary to avoid impacting the application's GUI (Graphical User Interface) response speed due to recording, especially to minimize CPU consumption during Input / Output serialization.

[0086] Therefore, in specific implementation, the recording scheme for the corresponding first function (js_Call) can be as follows: Before calling js_call, the C code serializes the C structure into a binary byte array using the protobuf serialization protocol. The protobuf serialization protocol is a platform-independent, language-independent, extensible, lightweight, and efficient serialization data format used to serialize custom data structures into byte streams and deserialize byte streams into data structures. Therefore, it is very suitable for data storage and data exchange format for communication between different languages ​​and applications. As long as the same protocol format is implemented, that is, files with the .proto extension are compiled into different language versions and added to their respective projects, different languages ​​can parse data serialized by other languages ​​through Protobuf. The C structure refers to the information entered by the user, such as the username and password entered by the user when logging into the application.

[0087] Then, the serialized result is passed as a function parameter to `js_call`, which calls `js_call`. The C `js_call` calls the JavaScript `jsCall`. In `jsCall`, the corresponding JavaScript function implementation for `JsCallCode` is called. This implementation serializes the JavaScript object in the return value into a binary byte array using protobuf and returns it to `jsCall`. Within `jsCall`, an extra copy of `JsCallCode` and the serialized return value is made; this is called `bridgeCall`.

[0088] In the embodiments of this specification, the return value of the execution of the first function can be recorded. For example, when the application displays a control to the user to confirm the purchase, and the user clicks to confirm, the user's click operation is the return value of the first function. The return value of the first function is recorded as a call parameter. This call operation can indicate the user's operation information in the target application. Subsequently, the cause of the fault can be accurately and efficiently located by replaying the call parameters.

[0089] In one optional implementation of this embodiment, the second calling parameter of the second type of code calling the first type of code is recorded through the second function. The specific implementation process can be as follows:

[0090] Obtain the second input information and serialize it to obtain the corresponding second function parameters;

[0091] Use the second function parameter as the input parameter of the second function, call the second function, and record the function parameters.

[0092] It should be noted that for WebAssembly, the input / output that is valuable for recording is the function parameters of the second function (wasmCall). The return value of the second function (wasmCall) is generated by executing the WebAssembly code, which can be reproduced during playback by executing the WebAssembly code without recording. Therefore, it is sufficient to record the function parameters of the second function during the calling process.

[0093] In practical implementation, the corresponding recording scheme for the second function (wasmCall) can be as follows: Before calling wasmCall, the JavaScript code serializes the JavaScript object into a binary byte array using the protobuf serialization protocol. Here, the JavaScript object contains the property information of the user-operated object; for example, if a user purchases a product, the JavaScript object can contain the product's property information. That is, the function parameter is the property information of the product purchased by the user. In actual implementation, other serialization protocols can also be used for serialization.

[0094] Then, the serialized result is used as the function parameter of wasmCall, and wasmCall is called. In wasmCall, an extra copy of WasmCallCode and the serialized function parameter is made, which is called bridgeCall.

[0095] As an example, the serialized data format of the saved bridgeCall can be as follows:

[0096]

[0097]

[0098]

[0099] In the embodiments of this specification, the function parameters of calling the second function can be recorded. For example, if a user purchases a product in the application, the function parameter is the attribute information of the product, which is used to call the corresponding second function. The function parameters of the second function are recorded as call parameters. This call operation can indicate the user's operation information in the target application. Subsequently, the cause of the fault can be accurately and efficiently located by replaying the call parameters.

[0100] In an optional implementation of this embodiment, the recorded call parameters can be stored; that is, after recording the call parameters on the data transmission channel, the method further includes:

[0101] The storage location identifier corresponding to the current session of the target application is recorded in the global variable of the second type of code, and the recorded call parameters are stored according to the storage location identifier.

[0102] Specifically, the target application may include multiple sessions that can be switched between. To avoid confusion in recorded call parameters, a corresponding storage location identifier can be assigned to each session. This storage location identifier can refer to a database identifier, meaning that the call parameters of one session are stored in one database; or it can refer to a storage block identifier within the database, meaning that the call parameters of all sessions are stored in the same database. Alternatively, a combination of the database identifier and the storage block identifier can be used to limit the storage location of the call parameters for the current session.

[0103] It should be noted that after starting a session of an application, the call parameters on the data transmission channel during operation can be recorded. Assuming that a user can only have one task being edited in each application, referred to as a session, when storing the call parameters of the current session of the target application, they can be stored based on the storage location identifier corresponding to the current session. When the user needs to report a fault in the current session, they only need to retrieve the recording file corresponding to the current session of the target application, making the operation simple and convenient.

[0104] In practical applications, when the target application starts and the session is opened, JavaScript code is executed. The JavaScript code records the storage location identifier corresponding to the current session of the target application in a global variable, and stores the call parameters recorded for the current session in the target storage location corresponding to the storage location identifier.

[0105] In one optional implementation of this embodiment, the recorded call parameters are stored according to the storage location identifier. The specific implementation process can be as follows:

[0106] Determine whether the target queue exceeds the length limit, where the target queue is the queue that stores the call parameters of the target application;

[0107] If the target queue does not exceed the length limit, the call parameters will be stored in the target queue;

[0108] Asynchronously consume the target queue and store the target queue in the target storage location corresponding to the storage location identifier.

[0109] It should be noted that after recording and obtaining the call parameter `bridgeCall`, it can be copied to a target queue `bridgeCalls` with a limited length. If the target queue exceeds the length limit, it will be discarded to avoid the queue becoming too long; otherwise, it will be copied. The call parameter `bridgeCall` includes the return value of the first recorded function (`js_Call`) and the function parameters of the second function (`wasmCall`), with the values ​​arranged in chronological order.

[0110] Then, the asynchronous `saveBridgeCall` JavaScript coroutine consumes the target queue `bridgeCalls`, saving the call parameter `bridgeCall` to the target storage location corresponding to the storage location identifier, such as the IndexedDB database provided by the browser. In this way, asynchronous consumption of the target queue `bridgeCalls` ensures asynchronous disk I / O operations when persisting the recorded call parameter `bridgeCall` to disk, reducing memory consumption.

[0111] Example, Figure 2b This is a flowchart illustrating the recording process of calling parameters according to an embodiment of this specification, such as... Figure 2b As shown, the return value of the first function (js_Call) and the function parameters of the second function (wasmCall) are added to the limited-length queue bridgeCalls in sequence according to the timing. Then, the asynchronous saveBridgeCall JavaScript coroutine consumes the limited-length queue bridgeCalls and writes it to the corresponding database IndexedDB.

[0112] Step 104: If a fault reporting command is detected from the target application, obtain the historical recording information corresponding to the target application.

[0113] It should be noted that when users need to report faults in the target application, the application management platform can detect fault reporting commands. For example, when WebAssembly code throws an exception, the application management platform can detect fault reporting commands.

[0114] In practical applications, when a fault report command is detected from the target application, it indicates that the target application has malfunctioned. At this time, the historical recording information corresponding to the target application can be obtained so as to replay the historical call parameters in the historical recording information and accurately and efficiently locate the cause of the target application's malfunction.

[0115] In an optional implementation of this embodiment, if the recorded call parameters are for the current session of the target application, and the storage location identifier corresponding to the current session is recorded in a global variable, the location storage identifier can be directly obtained from the global variable to obtain the historical recording information corresponding to the current session in the target application, that is, to obtain the historical recording information corresponding to the target application. The specific implementation can be as follows:

[0116] Retrieve the storage location identifier from the global variables, and then retrieve the historical recording information corresponding to the current conversation of the target application based on the storage location identifier.

[0117] It should be noted that the storage location identifier corresponding to the current conversation of the target application can be obtained from global variables. Then, based on the storage location identifier, the historical recording information corresponding to the current session of the target application can be directly extracted from the corresponding target storage location. The historical recording information can include various call parameters recorded during the current session of the target application. These call parameters can be the return value of the first function or the function parameters of the second function, which facilitates the direct playback of the historical call parameters included in the historical recording information to reproduce the current session of the target application and locate the cause of the fault.

[0118] Additionally, obtaining historical recording information for the target application allows you to attach this information to the fault report corresponding to the fault report command. This information can then be sent to staff via email or uploaded to the server. Staff can then download the attachment from the email or retrieve the historical recording information from the server.

[0119] For example, taking the storage location identifier as a database, the recorded call parameter bridgeCall can be retrieved from IndexedDB based on the database name, serialized into binary data, and sent as an attachment to the fault report email to the staff.

[0120] Step 106: Execute the code of the target application according to the historical call parameters in the historical recording information, and replay the execution data of the target application. The replayed execution data is used to determine the cause of the target application failure.

[0121] This execution data can indicate the internal state changes of the target application during code execution.

[0122] It's important to note that once staff receive a user-submitted fault report and extract the historical recording information, they can execute the target application's code through the application platform. The playback uses the exact same WebAssembly file as during recording, replacing only the JavaScript portion. The call parameters from the historical recording are used to replace the user input required for code execution, simulating the user's actual online operation. Playback also occurs in the target application's corresponding window, executing the JavaScript and WebAssembly code using the target application. In this way, when handling user-reported faults, staff can replay the historical recordings, executing each step to observe the actual output and the application's internal state, thereby improving the accuracy and efficiency of troubleshooting.

[0123] In one optional implementation of this embodiment, the code of the target application is executed according to the historical call parameters in the historical recording file, and the execution data of the target application is replayed. The specific implementation process can be as follows:

[0124] Determine the parameter type of the target call parameter and the target execution rule corresponding to the parameter type. The target call parameter is initially the first historical call parameter in the historical recording information.

[0125] Based on the target execution rules and target call parameters, execute the code of the target application and replay the execution data of the target application.

[0126] It should be noted that the historical call parameters in the recorded information can include two categories: the return value of the first function and the function parameters of the second function. The execution rules for different types of call parameters are not the same; that is, the target execution rules corresponding to different parameter types can be different. The recorded information can be a serialized binary file or a deserialized array. Each value in this array represents a call parameter, and the array index indicates the sorting order of the call parameters, also known as the time sequence.

[0127] As an example, the execution rule for the return value type can be to run the code based on the current target call parameters, and then continue to traverse the next call parameter of the current target call parameters in the historical recording information, that is, array index i plus 1; the execution rule for the function parameter type can be to run the code based on the current target call parameters and the set number of call parameters that follow, and then continue to traverse the set number of call parameters after the current call parameters in the historical recording information, that is, the set number of call parameters after the current target call parameters are not traversed, and the call parameters corresponding to i plus N+1 are directly traversed, where N is the array index of the current target call parameters.

[0128] The set value corresponds to the number of times the first function is called during the process of calling the second function. For example, if the first function is called once during the process of calling the second function, the (i+1)th call parameter is directly used to implement the call of the first function without needing to traverse. At this time, we can continue to traverse the (i+2)th call parameter.

[0129] In the embodiments of this specification, the execution rules for each call parameter are determined by combining the parameter types of each call parameter in the historical recording information. The execution rules reflect the traversal rules of different types of call parameters in the historical recording information. The execution rules are based on the actual running logic configuration, thereby ensuring that the playback process traverses the call parameters according to the actual running logic, accurately replays the actual online running screen and internal state of the target application, so as to ensure accurate and efficient location of the cause of the fault.

[0130] In one optional implementation of this embodiment, the code of the target application is executed according to the target execution rules and target calling parameters, and the execution data of the target application is replayed. The specific implementation process can be as follows:

[0131] If the parameter type is a return value type, reproduce the process of calling the first function based on the return value, replay the function parameters of the first function, and take the next call parameter of the target call parameter in the historical recording information as the updated target call parameter, and return to execute the operation steps to determine the parameter type of the target call parameter;

[0132] If the parameter type is a function parameter type, reproduce the process of calling the second function according to the function parameters, replay the return value of the second function, update the target call parameters based on the process of calling the second function, and return to execute the operation steps that determine the parameter type of the target call parameters.

[0133] It should be noted that when replaying call parameters with return values, the first function is executed based on the call parameter. The execution of the first function does not involve the call of the second function. Therefore, after the replay is completed, the next call parameter in the historical recording information can be directly traversed. This ensures that the replay process traverses the call parameters according to the actual running logic, accurately replays the actual online running screen and internal state of the target application, and ensures accurate and efficient location of the cause of the fault.

[0134] In one optional implementation of this embodiment, the target calling parameters are updated based on the process of calling the second function. The specific implementation process can be as follows:

[0135] If the first function is called during the process of calling the second function, the set value of the call parameters after the target call parameters is obtained from the historical recording information. The first function is called according to the set value of the call parameters, and the target call parameters are updated according to the set value.

[0136] It should be noted that when replaying the function parameter type call parameters, the second function is executed based on the call parameters. During the execution of the second function, the first function will be called. Therefore, the process of replaying the second function needs to determine the return value required to execute the first function (i.e., the next call parameter of the function parameter) from the historical recording information to execute the first function. After the replay is completed, the next call parameter of the return value in the historical recording information is directly traversed, that is, the call parameter after the function parameter currently being traversed. This ensures that the replay process traverses the call parameters according to the actual running logic, accurately replays the actual online running screen and internal state of the target application, and ensures accurate and efficient location of the cause of the fault.

[0137] In practical applications, given a list of call parameters `bridgeCall` extracted from historical recordings, represented as a `bridgeCall[]` array, each `bridgeCall`'s array index `code` is either `JsCallCode` or `WasmCallCode`, corresponding to the index position of a call parameter `bridgeCall` within the `bridgeCall[]` array. During playback, the recorded `WasmCall` function parameters in the `bridgeCall[]` array are traversed sequentially, and `replayWasmCall` is executed. `replayWasmCall` replays `WasmCall` by calling the `wasm_call` function in `WebAssembly`. During `WasmCall` playback, the internal implementation of `WebAssembly` calls the JavaScript-side `window.jsCall`. Before playback, `window.jsCall` is replaced with the playback version of `replayJsCall`, i.e., the call parameters in the `bridgeCall[]` array. `replayJsCall` and `replayWasmCall` share the same array traversal index `replayIndex`, meaning that replayed call parameters are not traversed again, and the corresponding array index is skipped.

[0138] As an example, the replay code could be as follows:

[0139]

[0140]

[0141] Example, Figure 2c This description, in its first embodiment, illustrates a process for traversing parameters in historical recording information, as shown below. Figure 2cAs shown, the historical recording information is a `bridgeCall[]` array. The current array index `i` equals 2. The current target call parameter is the second call parameter in the `bridgeCall[]` array of the historical recording information. The parameter type of this second call parameter is a function parameter type. Based on this second call parameter, the second function `wasmCall` is replayed, i.e., `replaywasmCall`. The corresponding `wasm_Call` function in `WebAssembly` is called. After calling `wasm_Call`, the first function `js_Call` is also called once in `WebAssembly`. The third call parameter in the `bridgeCall[]` array of the historical recording information is determined as the return value of JavaScript. The first function `js_Call` is then replayed, i.e., `replayjs_Call`. Then, let `i = 4`. The current target call parameter is the fourth call parameter in the historical recording information. The parameter type of this fourth call parameter is determined, and the above response process is repeated until the last call parameter.

[0142] It's important to note that when staff replay historical recordings, aside from replacing the call parameters recorded on the data transmission channel, the rest of the code is identical to the production environment. This ensures that the playback process truly runs the code being debugged, reconstructing the target application's internal state before the failure occurred. This allows staff to observe the target application's internal state during playback and obtain more direct fault diagnosis information. Furthermore, playback can reproduce the WebAssembly output on the Canvas, eliminating the need to record the Canvas itself and saving recording resources.

[0143] The troubleshooting method for applications provided in this specification allows for the recording of call parameters on the data transmission channel between the first type of code and the second type of code in the target application during its operation. These call parameters reflect the operations performed by the user in the target application. Therefore, when a fault occurs in the target application, the code of the target application can be re-executed based on the historical call parameters recorded during previous operation, and the execution data of the target application can be replayed. The process of replaying the execution data will reproduce the running screen of the target application, thus eliminating the need to record the running screen of the target application. By combining the execution data of the target application with the reproduced running screen, the operator can determine the cause of the target application's fault, thereby improving the accuracy and efficiency of troubleshooting the cause of the target application's fault.

[0144] The following is in conjunction with the appendix Figure 3Taking the application troubleshooting methods provided in this manual in a browser scenario as an example, this paper further explains the application troubleshooting methods. Figure 3 This specification illustrates a flowchart of a troubleshooting method for an application in a browser environment, based on an embodiment of this specification. The method specifically includes the following steps:

[0145] Step 302: For web applications running in a browser that use WebAssembly, standardize the communication channel between WebAssembly and JavaScript through the application management platform.

[0146] It should be noted that step 302 may specifically include the following steps:

[0147] By changing all calls from WebAssembly to JavaScript to js_call, the return value of the JavaScript function can be recorded on js_call.

[0148] By changing all JavaScript calls to WebAssembly to calls to wasmCall, the function parameters required to call functions in WebAssembly can be recorded on wasmCall.

[0149] Step 304: Record all input / output data on the WebAssembly and JavaScript communication channels while the user is using the web application.

[0150] It should be noted that this involves full recording of input / output on the WebAssembly and JavaScript communication channels, including both the js_Call and wasmCall recording schemes.

[0151] The js_Call recording scheme is as follows: Before calling js_call, the C code serializes the C structure into a binary byte array using the protobuf serialization protocol; the serialization result is used as the parameter of js_call, and js_call is called; the C js_call calls the JavaScript jsCall; in jsCall, the corresponding JsCallCode's JavaScript function implementation is called; the corresponding JsCallCode's JavaScript function implementation serializes the JavaScript object in the return value into a binary byte array using protobuf, and returns the return value to jsCall; in jsCall, an additional copy of JsCallCode and the serialized return value is made, called bridgeCall; bridgeCall is copied to a queue with a limited length, bridgeCalls, and is discarded if the queue exceeds the length limit; the asynchronous saveBridgeCall JavaScript coroutine consumes the bridgeCalls queue and saves the bridgeCalls queue to the browser's IndexedDB.

[0152] The wasmCall recording scheme is as follows: Before calling wasmCall, the JavaScript code serializes the JavaScript object into a binary byte array using the protobuf serialization protocol; the serialized result is then used as the parameter for wasmCall, and wasmCall is called; within wasmCall, an additional copy of WasmCallCode and the serialized parameter is made, called bridgeCall. bridgeCall is copied to a queue with a limited length, bridgeCalls; if the queue exceeds the length limit, it is discarded; the asynchronous saveBridgeCall JavaScript coroutine consumes the bridgeCalls queue and saves the bridgeCalls queue to the browser's IndexedDB.

[0153] Step 306: When a user reports a malfunction in the web application, extract and report the historical recording information.

[0154] It should be noted that the extraction and reporting of historical recording information may include the following steps: When a browser tab is opened, JavaScript code is executed; the JavaScript code records the database name of IndexedDB corresponding to the current browser tab in a global variable; when the user needs to report a fault, such as when WebAssembly code throws an exception, the database name of IndexedDB is obtained from the global variable; based on the database name, the recorded bridgeCall is retrieved from IndexedDB, serialized into binary data, and sent as an attachment to the fault report.

[0155] Step 308: When staff are handling user-reported faults on the application management platform, they replay the historical recordings in the attachments, execute them step by step to observe the actual Cavans output and the internal state of the web application, and locate the cause of the fault.

[0156] It should be noted that when staff receive a fault report from a user, they extract the historical recording information as an attachment. Playback uses the exact same WebAssembly file as the recording. Only the JavaScript portion needs to be replaced. Playback also occurs in a browser window, executed by the browser using JavaScript and WebAssembly.

[0157] Given a list of bridgeCalls extracted from a recording file as a bridgeCall[] array, each bridgeCall's code is either JsCallCode or WasmCallCode, which corresponds to an index position in the bridgeCall[] array.

[0158] During playback, the recorded WasmCall calls in the bridgeCall[] array are traversed sequentially, and replayWasmCall is executed. replayWasmCall replays WasmCall by calling the wasm_call function in WebAssembly. During WasmCall playback, the internal implementation of WebAssembly calls the JavaScript-side window.jsCall. Before playback, window.jsCall is replaced with the playback version of replayJsCall. replayJsCall and replayWasmCall share the same array traversal index, replayIndex.

[0159] The troubleshooting method for applications provided in this specification, during the operation of a web application using WebAssembly running in a browser, can record the input / output on the communication channel between WebAssembly and JavaScript in the web application. This input / output reflects the operations performed by the user in the web application. Therefore, when the web application malfunctions, the code of the web application can be re-executed based on the input / output recorded during previous operation. The process of replaying the execution data will reproduce the Cavans output of the web application and the internal state of the web application, thus eliminating the need to record the Cavans output of the web application. By combining the execution data of the web application and the reproduced Cavans output, the operator can determine the cause of the web application malfunction, improving the accuracy and efficiency of troubleshooting web application malfunctions.

[0160] Corresponding to the above method embodiments, this specification also provides embodiments of an application troubleshooting device. Figure 4 A schematic diagram of the structure of a troubleshooting device for an application provided in one embodiment of this specification is shown. Figure 4 As shown, the device includes:

[0161] The recording module 402 is configured to record the call parameters on the data transmission channel when the target application is started, wherein the code of the target application includes a first type of code and a second type of code, and the data transmission channel is used to implement function calls between the first type of code and the second type of code in the target application;

[0162] The acquisition module 404 is configured to acquire the historical recording information corresponding to the target application if a fault reporting instruction of the target application is detected.

[0163] The playback module 406 is configured to execute the code of the target application based on the historical call parameters in the historical recording information, and to replay the execution data of the target application, wherein the replayed execution data is used to determine the cause of the failure of the target application.

[0164] Optionally, the device also includes a modification module configured to:

[0165] Modify the location in the target application's code where the first type of code calls the second type of code to call the first function;

[0166] Modify the location in the target application's code where the second type of code calls the first type of code to call the second function;

[0167] Among them, the first function and the second function are pre-encapsulated functions used to record the call parameters of the function call process.

[0168] Optionally, the recording module 402 is further configured as follows:

[0169] The first function records the first call parameter of the first type of code calling the second type of code, and the second function records the second call parameter of the second type of code calling the first type of code.

[0170] Optionally, the recording module 402 is further configured as follows:

[0171] Obtain the first input information and serialize it to obtain the corresponding first function parameters;

[0172] The first function is executed according to its input parameters, and the return value of the first function is obtained and recorded.

[0173] Optionally, the recording module 402 is further configured as follows:

[0174] Obtain the second input information and serialize it to obtain the corresponding second function parameters;

[0175] Use the second function parameter as the input parameter of the second function, call the second function, and record the function parameters.

[0176] Optionally, the recording module 402 is further configured as follows:

[0177] The storage location identifier corresponding to the current session of the target application is recorded in the global variable of the second type of code, and the recorded call parameters are stored according to the storage location identifier;

[0178] Accordingly, module 404 is further configured as follows:

[0179] Retrieve the storage location identifier from the global variables, and then retrieve the historical recording information corresponding to the current session of the target application based on the storage location identifier.

[0180] Optionally, the recording module 402 is further configured as follows:

[0181] Determine whether the target queue exceeds the length limit, where the target queue is the queue that stores the call parameters of the target application;

[0182] If the target queue does not exceed the length limit, the call parameters will be stored in the target queue;

[0183] Asynchronously consume the target queue and store the target queue in the target storage location corresponding to the storage location identifier.

[0184] Optionally, the playback module 406 is further configured as follows:

[0185] Determine the parameter type of the target call parameter and the target execution rule corresponding to the parameter type. The target call parameter is initially the first historical call parameter in the historical recording information.

[0186] Based on the target execution rules and target call parameters, execute the code of the target application and replay the execution data of the target application.

[0187] Optionally, the playback module 406 is further configured as follows:

[0188] If the parameter type is a return value type, reproduce the process of calling the first function based on the return value, replay the function parameters of the first function, and take the next call parameter of the target call parameter in the historical recording information as the updated target call parameter, and return to execute the operation steps to determine the parameter type of the target call parameter;

[0189] If the parameter type is a function parameter type, reproduce the process of calling the second function according to the function parameters, replay the return value of the second function, update the target call parameters based on the process of calling the second function, and return to execute the operation steps that determine the parameter type of the target call parameters.

[0190] Optionally, the playback module 406 is further configured as follows:

[0191] If the first function is called during the process of calling the second function, the set value of the call parameters after the target call parameters is obtained from the historical recording information. The first function is called according to the set value of the call parameters, and the target call parameters are updated according to the set value.

[0192] The troubleshooting device for the application provided in this specification can record the call parameters on the data transmission channel of function calls between the first type of code and the second type of code in the target application during the operation of the target application. These call parameters can reflect the operations performed by the user in the target application. Therefore, when the target application malfunctions, the code of the target application can be re-executed based on the historical call parameters recorded during previous operation, and the execution data of the target application can be replayed. The process of replaying the execution data will reproduce the running screen of the target application, thus eliminating the need to record the running screen of the target application. By combining the execution data of the target application and the reproduced running screen, the operator can determine the cause of the target application malfunction, thereby improving the accuracy and efficiency of troubleshooting the cause of the target application malfunction.

[0193] The above is a schematic scheme of an application troubleshooting device according to this embodiment. It should be noted that the technical solution of the application troubleshooting device and the technical solution of the application troubleshooting method described above belong to the same concept. For details not described in detail in the technical solution of the application troubleshooting device, please refer to the description of the technical solution of the application troubleshooting method described above.

[0194] Figure 5 A structural block diagram of a computing device according to an embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0195] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0196] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0197] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 500 can also be a mobile or stationary server.

[0198] The processor 520 is used to execute the following computer-executable instructions to implement the steps of the above-described troubleshooting method for the application.

[0199] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described application troubleshooting method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described application troubleshooting method.

[0200] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, are used to implement the steps of the above-described troubleshooting method for an application program.

[0201] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the application troubleshooting method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the application troubleshooting method described above.

[0202] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0203] Computer instructions include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0204] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this specification is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this specification. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this specification.

[0205] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0206] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. These embodiments have been selected and specifically described in this specification to better explain the principles and practical applications of this specification, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for troubleshooting an application, characterized in that, The method includes: When the target application is launched, the call parameters on the data transmission channel are recorded. The code of the target application includes a first type of code and a second type of code. The first type of code is WebAssembly, and the second type of code is JavaScript. The data transmission channel is used to implement function calls between the first type of code and the second type of code in the target application. The data transmission channel between the first type of code and the second type of code in the target application is configured as follows: the call location where the first type of code calls the second type of code in the code of the target application is modified to call a first function; the call location where the second type of code calls the first type of code in the code of the target application is modified to call a second function; wherein the first function and the second function are pre-encapsulated functions used to record the call parameters of the function call process. If a fault reporting command of the target application is detected, the historical recording information corresponding to the target application is obtained; Based on the historical call parameters in the historical recording information, the code of the target application is executed, and the execution data of the target application is replayed, wherein the replayed execution data is used to determine the cause of the failure of the target application.

2. The method according to claim 1, characterized in that, The recording of call parameters on the data transmission channel includes: The first function records the first call parameters of the first type of code calling the second type of code, and the second function records the second call parameters of the second type of code calling the first type of code.

3. The method according to claim 2, characterized in that, The first call parameter for recording the first type of code calling the second type of code through the first function includes: Obtain the first input information and serialize the first input information to obtain the corresponding first function parameters; The input parameters of the first function are executed according to the parameters of the first function, and the return value of the first function is obtained and recorded.

4. The method according to claim 2, characterized in that, The second call parameter for recording the second type of code calling the first type of code through the second function includes: Obtain the second input information and serialize the second input information to obtain the corresponding second function parameters; Use the second function parameters as input parameters for the second function, call the second function, and record the function parameters.

5. The method according to any one of claims 1-4, characterized in that, After recording the call parameters on the data transmission channel, the method further includes: The storage location identifier corresponding to the current session of the target application is recorded in the global variable of the second type of code, and the recorded call parameters are stored according to the storage location identifier; Accordingly, obtaining the historical recording information corresponding to the target application includes: Obtain the storage location identifier from the global variable, and obtain the historical recording information corresponding to the current session of the target application based on the storage location identifier.

6. The method according to claim 5, characterized in that, The step of storing the recorded call parameters according to the storage location identifier includes: Determine whether the target queue exceeds the length limit, wherein the target queue is a queue that stores the calling parameters of the target application; If the target queue does not exceed the length limit, the calling parameters are stored in the target queue; The target queue is consumed asynchronously, and the target queue is stored in the target storage location corresponding to the storage location identifier.

7. The method according to claim 1, characterized in that, The step of executing the target application's code based on the historical call parameters in the historical recording information and replaying the target application's execution data includes: Determine the parameter type of the target call parameter and the target execution rule corresponding to the parameter type, wherein the target call parameter is initially the first historical call parameter in the historical recording information; According to the target execution rules and the target invocation parameters, the code of the target application is executed, and the execution data of the target application is replayed.

8. The method according to claim 7, characterized in that, The step of executing the code of the target application according to the target execution rule and the target invocation parameters, and replaying the execution data of the target application, includes: When the parameter type is a return value type, the process of calling the first function is reproduced according to the return value, the function parameters of the first function are replayed, and the next call parameter of the target call parameter in the historical recording information is used as the updated target call parameter. Then, the operation step of determining the parameter type of the target call parameter is returned to be executed. If the parameter type is a function parameter type, the process of calling the second function is reproduced according to the function parameter, the return value of the second function is replayed, the target call parameter is updated based on the process of calling the second function, and the operation steps of determining the parameter type of the target call parameter are returned.

9. The method according to claim 8, characterized in that, The process of updating the target call parameters based on calling the second function includes: If the first function is called during the process of calling the second function, then a set number of call parameters after the target call parameters are obtained from the historical recording information, the first function is called according to the set number of call parameters, and the target call parameters are updated according to the set value.

10. A troubleshooting device for an application, characterized in that, The device includes: A recording module is configured to record call parameters on a data transmission channel when the target application is launched. The target application's code includes a first type of code and a second type of code. The first type of code is WebAssembly, and the second type of code is JavaScript. The data transmission channel is used to implement function calls between the first and second types of code in the target application. The data transmission channel between the first and second types of code in the target application is configured as follows: the call location where the first type of code calls the second type of code in the target application's code is modified to call a first function; the call location where the second type of code calls the first type of code in the target application's code is modified to call a second function; wherein the first and second functions are pre-encapsulated functions used to record call parameters during the function call process. The acquisition module is configured to acquire historical recording information corresponding to the target application if a fault reporting instruction of the target application is detected. The playback module is configured to execute the code of the target application based on the historical call parameters in the historical recording information, and to play back the execution data of the target application, wherein the played-back execution data is used to determine the cause of the failure of the target application.

11. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the steps of the troubleshooting method for the application program according to any one of claims 1-9.

12. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the troubleshooting method for the application program according to any one of claims 1-9.

Images