Abnormality analysis method and device, electronic equipment and computer readable storage medium

Abstract

The invention discloses an exception analysis method and device, electronic equipment and a computer readable storage medium, relates to the technical field of computers, and can be used for exception analysis of an application function component. The application function component has an abnormal operation event related to a hardware device of the target entity equipment; creating a virtual device corresponding to the target entity device through the device simulator; a pre-generated real machine plug-in corresponding to the target entity device is loaded through the device simulator, the real machine plug-in comprises a to-be-debugged function of the application function component, and the to-be-debugged function is a function having a calling relation with the hardware device; obtaining device data of which the data type is the same as that of the hardware device, providing the device data to the virtual equipment, and debugging the to-be-debugged function by utilizing the device data through the virtual equipment according to the abnormal operation event; and obtaining debugging data of the to-be-debugged function in the debugging process, and determining an abnormal reason of the abnormal operation event according to the debugging data.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to an anomaly analysis method, an anomaly analysis device, an electronic device, and a computer-readable storage medium. Background Art

[0002] Currently, electronic devices such as mobile phones and tablets can install a variety of applications, thereby expanding their capabilities. For example, instant messaging applications can be installed on electronic devices to expand their instant messaging capabilities. Applications are composed of application functional components that implement different functions. For example, an instant messaging application is composed of application functional components that implement functions such as communication, scanning, and shaking.

[0003] It's understandable that various abnormal events may occur during the operation of applications installed on electronic devices. In related technologies, to analyze the causes of these abnormal events and prevent them from recurring, device simulators are often used to simulate portions of the environment of a real device, allowing the simulator to reproduce the abnormal events and conduct analysis. However, current device simulators can only simulate software environments and are unable to reproduce hardware-related abnormal events, making it impossible to analyze these hardware-related abnormal events. Summary of the Invention

[0004] The embodiments of the present application provide an anomaly analysis method, an anomaly analysis device, an electronic device, and a computer-readable storage medium, which can implement an anomaly analysis of abnormal events related to hardware devices.

[0005] In a first aspect, the anomaly analysis method provided by the present application includes:

[0006] Determine the target physical device on which the application functional component requiring abnormal analysis is running, where the application functional component has an abnormal operation event related to the hardware device of the target physical device;

[0007] Create a virtual device corresponding to the target physical device through the device simulator. The device model and system version of the virtual device are the same as those of the target physical device.

[0008] Loading a pre-generated real device plug-in corresponding to the target physical device through the device simulator, the real device plug-in includes the to-be-debugged function of the application functional component, and the to-be-debugged function is a function that has a calling relationship with the hardware device;

[0009] Obtaining device data of the same data type as the hardware device and providing it to the virtual device, and debugging the function to be debugged by using the device data through the virtual device according to the abnormal operation event;

[0010] Obtain debugging data of the function to be debugged during the debugging process, and determine the abnormal cause of the abnormal operation event based on the debugging data.

[0011] In a second aspect, the present application provides an abnormality analysis device, comprising:

[0012] A device determination module is used to determine a target physical device on which an application functional component requiring abnormality analysis is running, where an abnormal operation event of the application functional component is related to a hardware device of the target physical device;

[0013] The device simulation module is used to create a virtual device corresponding to the target physical device through the device simulator. The device model and system version of the virtual device are the same as those of the target physical device.

[0014] A plug-in loading module is used to load a pre-generated real-device plug-in corresponding to a target physical device through a device simulator. The real-device plug-in includes a function to be debugged of an application functional component. The function to be debugged is a function that has a calling relationship with a hardware device.

[0015] The function debugging module is used to obtain device data of the same data type as the hardware device and provide it to the virtual device, and debug the function to be debugged by using the device data through the virtual device according to an abnormal operation event;

[0016] The exception analysis module is used to obtain the debugging data of the function to be debugged during the debugging process, and determine the abnormal cause of the abnormal operation event based on the debugging data.

[0017] Optionally, in one embodiment, the function debugging module is used to determine a data acquisition method that matches the data source method configured by the application functional component; and according to the data acquisition method, obtain device data with the same data type as the hardware device and provide it to the virtual device.

[0018] Optionally, in one embodiment, the function debugging module is used to, if the determined data acquisition method is the first data acquisition method, obtain device data of the same data type as the hardware device from a local hardware device of the same device type as the hardware device and provide it to the virtual device; or, if the determined data acquisition method is the second data acquisition method, start a state machine of the corresponding target physical device through the virtual device, and obtain device data of the same data type as the hardware device based on the state machine and provide it to the virtual device; or, if the determined data acquisition method is the third data acquisition method, obtain device data of the same data type as the hardware device from a remote physical device whose device type and system version are the same as those of the target physical device and provide it to the virtual device.

[0019] Optionally, in one embodiment, the exception analysis module creates a target calling object that complies with the calling rules of the abnormal function to be debugged in response to the data exception of the execution result data of the function to be debugged; and replaces the current calling object of the abnormal function to be debugged with the target calling object; and obtains the first execution result data of the abnormal function to be debugged, and obtains the second execution result data of other functions to be debugged that have an execution dependency relationship with the abnormal function to be debugged; and uses the first execution result data and the second execution result data as debugging data.

[0020] Optionally, in one embodiment, the exception analysis device provided by the present application also includes a plug-in generation module for identifying the target function of the hardware device that calls the target entity device in the application functional component; and marking the identified target function as a function to be debugged, and generating a real machine plug-in corresponding to the target entity device based on the function to be debugged.

[0021] Optionally, in one embodiment, the plug-in generation module is used to encapsulate the function to be debugged into a real machine plug-in corresponding to the target physical device by using a debugging tool that matches the system type of the target physical device.

[0022] Optionally, in one embodiment, the plug-in generation module is used to perform at least one of the following: obtaining a static library of the device architecture corresponding to the target entity device, and identifying the target function of the hardware device of the target entity device in the application function component based on the static library; hooking the proxy method of calling the hardware device of the corresponding target entity device, and identifying the target function of the hardware device of the target entity device in the application function component based on the function address after the hook; determining the configuration file of the hardware device of the corresponding target entity device, and identifying the target function of the hardware device of the target entity device in the application function component based on the configuration file; detecting the device data of the hardware device input from the outside of the application function component, and identifying the target function of the hardware device of the target entity device in the application function component based on the device data.

[0023] In a third aspect, the electronic device provided in the present application includes a memory and a processor, the memory stores a computer program, and the processor is used to run the computer program in the memory to implement the steps in the anomaly analysis method provided in the present application.

[0024] In a fourth aspect, the computer-readable storage medium provided in the present application stores a computer program, which is suitable for being run by a processor to implement the steps in the anomaly analysis method provided in the present application.

[0025] The abnormality analysis scheme provided by the present application determines the physical device on which the application function component to be analyzed for abnormality is running, and the application function component has an abnormal operation event related to the hardware device of the physical device; creates a virtual device corresponding to the physical device through a device simulator, and the device model and system version of the virtual device are the same as the device model and system version of the physical device; loads a pre-generated real-machine plug-in corresponding to the physical device through the device simulator, and the real-machine plug-in includes a function to be debugged of the application function component, and the function to be debugged is a function that has a call relationship with the hardware device; obtains device data of the same data type as the hardware device, and debugs the function to be debugged through the virtual device using the device data according to the abnormal operation event; obtains debugging data of the function to be debugged during the debugging process, and determines the abnormal cause of the abnormal operation event based on the debugging data. In this way, in addition to the simulation capability of the simulator's own software environment, by obtaining device data of the same data type as the hardware device on the physical device and providing it to the virtual device, the hardware environment of the physical device can be constructed, so that the function to be debugged in the real-machine plug-in can be debugged in the same software and hardware environment as the simulated physical device to reproduce the abnormal operation event, and the abnormal cause of the abnormal operation event can be determined using the debugging data during the debugging process. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0027] Figure 1a This is a schematic diagram of a scenario of an abnormality analysis system provided by an embodiment of the present application;

[0028] Figure 1b Schematic diagram of the process of the abnormality analysis method provided in the embodiment of the present application;

[0029] Figure 1c This is an example diagram of creating a virtual device corresponding to a target physical device in an embodiment of the present application;

[0030] Figure 1d This is an example diagram of the data acquisition method provided in the embodiments of the present application;

[0031] Figure 1e is a schematic diagram of following abnormal data in an embodiment of the present application;

[0032] Figure 1f This is an example diagram of identifying the target function in the embodiment of the present application;

[0033] Figure 2This is another flowchart of the abnormality analysis method provided in an embodiment of the present application;

[0034] Figure 3 This is a schematic diagram of the structure of the abnormality analysis device provided in an embodiment of the present application;

[0035] Figure 4 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] It should be noted that the principles of this application are illustrated by implementing them in an appropriate computing environment. The following description is based on the illustrated specific embodiments of this application and should not be considered as limiting other specific embodiments not described in detail herein.

[0037] In the following description of this application, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

[0038] In the following description of this application, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0040] In order to enable abnormal analysis of abnormal events related to hardware devices, the present application provides an abnormality analysis method, an abnormality analysis device, an electronic device, a computer-readable storage medium, and a computer program product. The abnormality analysis method can be executed by the abnormality analysis device, or by an electronic device integrated with the abnormality analysis device.

[0041] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described below are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts are within the scope of protection of this application.

[0042] Please refer to Figure 1aThe present application provides an exception analysis system, which includes an electronic device 100 for executing the exception analysis method provided by the present application. The electronic device 100 can be any device that can run a device simulator, wherein the physical device on which the application function component that needs to be analyzed for exception is run is determined, and the application function component has an abnormal operation event related to the hardware device of the physical device; a virtual device corresponding to the physical device is created through the device simulator, and the device model and system version of the virtual device are the same as the device model and system version of the physical device; a real machine plug-in corresponding to the physical device is loaded through the device simulator, and the real machine plug-in includes a function to be debugged of the application function component, and the function to be debugged is a function that has a call relationship with the hardware device; device data with the same data type as the hardware device is obtained, and according to the abnormal operation event, the function to be debugged is debugged through the virtual device using the device data; the debugging data of the function to be debugged during the debugging process is obtained, and the abnormal cause of the abnormal operation event is determined according to the debugging data. In this way, based on the additional real machine plug-in to generate the hardware environment of the physical device, the abnormal events related to the hardware device can be reproduced, thereby realizing the abnormal analysis of the abnormal events related to the hardware device.

[0043] In addition, if Figure 1a As shown, the abnormality analysis system may further include a memory 200 for storing relevant data during the abnormality analysis process, such as original data such as acquired device data, intermediate data such as debugging data during the debugging process, and result data such as determined abnormality causes.

[0044] It should be noted that the anomaly analysis system described above is merely an example, which is intended to more clearly illustrate the technical solution of the embodiment of the present application and does not constitute a limitation on the technical solution provided by the embodiment of the present application. Ordinary technicians in this field will know that with the evolution of the anomaly analysis system and the emergence of new business scenarios, the technical solution provided by the embodiment of the present application is also applicable to similar technical problems.

[0045] It should be noted that the serial numbers of the following embodiments are not intended to limit the preferred order of the embodiments.

[0046] Please refer to Figure 1b ,This embodiment provides an abnormality analysis method, such as Figure 1b As shown, the process of the abnormality analysis method is as follows:

[0047] In 110 , a target physical device on which an application functional component requiring abnormality analysis is running is determined, and an abnormal operation event related to a hardware device of the target physical device occurs in the application functional component.

[0048] Application components are programmable, reusable, typically self-contained, and language-independent software units that can be easily used to build applications. For example, an instant messaging application might include components for chat, address book, scan, and shake, among others.

[0049] It is understandable that during the operation of an application, its application functional components will inevitably encounter various anomalies. For example, taking the application functional component that implements the scan function as an example, this application functional component needs to call the camera to collect image data, and then analyze the image data to obtain the analysis results. Anomalies may occur in each link of the process from acquiring image data to analyzing the analysis results, causing the scan function to fail. This application aims to analyze the anomalies of these application functional components that have abnormal operation events related to the hardware components of the physical device and determine the corresponding causes of the anomalies.

[0050] In an embodiment of the present application, an application functional component requiring abnormality analysis is first determined, that is, an application functional component experiencing an abnormal operation event related to a hardware component of a physical device, and the physical device on which the application functional component is running when the aforementioned abnormal operation event occurs is determined, which is recorded as the target physical device. For example, an instant messaging application is installed on a physical device, and the instant messaging application includes an application functional component that uses data from a gyroscope and a positioning device to implement a shake function. If the shake function of the application functional component is abnormal, the application functional component can be determined as an application functional component requiring abnormality analysis, and the physical device on which the application functional component is running is the target physical device.

[0051] In 120 , a virtual device corresponding to the target physical device is created through a device simulator. The device model and system version of the virtual device are the same as those of the target physical device.

[0052] The device simulator is limited to its ability to simulate the architecture and system of a physical device. Those skilled in the art can select an appropriate device simulator based on their actual needs. For example, the exception analysis method provided in this application can be executed on an X86-based desktop computer. This desktop computer can use the device simulator to simulate a physical mobile device with an ARM architecture and corresponding system version, and create a corresponding virtual mobile device.

[0053] In the embodiment of the present application, after determining the target physical device on which the application functional component to be analyzed for abnormality is running, the device model and system version of the target physical device are further determined, and then a virtual device with the same device model and system version as the target physical device is created according to the device model and system version of the target physical device. For example, please refer to Figure 1c The electronic device that executes the exception analysis method provided in this application is a desktop computer. The device model of the target physical device on which the application functional component that needs to be analyzed for exception runs is "xphone14" and the system version is "os16.4". Accordingly, a virtual device with a device model of "xphone14" and a system version of "os16.4" is created through the device simulator run by the desktop computer to realize the simulation of the target physical device.

[0054] In 130 , a pre-generated real device plug-in corresponding to the target physical device is loaded through the device simulator. The real device plug-in includes a function to be debugged corresponding to the hardware device in the application functional component.

[0055] It should be noted that in the embodiment of the present application, for an application function component, a real machine plug-in corresponding to the device architecture is pre-generated for physical devices of different device architectures. The real machine plug-in includes the to-be-debugged functions of the hardware devices in the physical devices of the different device architectures in the application function component, wherein the to-be-debugged functions include functions related to the function calls of the hardware devices. For example, for a sub-function in an application function component, the sub-function is implemented by the coordination of three functions, namely function A, function B, and function C. Function A is used to process device data from a hardware device, function B is used to further process the processing result obtained by processing function A, and function C is used to further process the processing result obtained by processing function B to obtain the final result for the implementation of the sub-function. Function A, function B, and function C are all functions related to the function call of the hardware device.

[0056] As described above, after creating a virtual device corresponding to the target physical device through the device simulator, the pre-generated real device plug-in of the device architecture corresponding to the target physical device is further loaded through the device simulator, thereby adding the functions to be debugged included in the real device plug-in to the created virtual device.

[0057] In 140 , device data having the same data type as the hardware device is obtained and provided to the virtual device. The virtual device uses the device data to debug the function to be debugged.

[0058] In the embodiment of the present application, device data of the same data type as the hardware device related to the abnormal operation event on the target entity device is also obtained, thereby realizing the construction of the hardware environment of the target entity device. For example, assuming that the abnormal operation event is an abnormal operation event related to a positioning device, then the device data of the same data type as the positioning device is obtained accordingly, that is, positioning data; assuming that the abnormal operation event is an abnormal operation event related to a motion sensor such as a gyroscope, then the device data of the same data type as the motion sensor is obtained accordingly, that is, motion data; assuming that the abnormal operation event is an abnormal operation event related to a camera, then the device data of the same data type as the camera is obtained accordingly, that is, image data.

[0059] As mentioned above, after obtaining device data with the same data type as the hardware device, the obtained device data is provided to the virtual device created by the device simulator, and further abnormal operation events occurring in the application function components for abnormal analysis as needed are performed. The virtual device created by the device simulator uses the obtained device data to debug the function to be debugged to reproduce the abnormal operation event.

[0060] It should be noted that the acquired device data can be provided to the virtual device created by the device simulator using a process communication method. Process communication methods include, but are not limited to, shared memory mode, message passing mode, and shared file mode, and can be selected by those skilled in the art based on actual needs.

[0061] Optionally, in one embodiment, obtaining device data having the same data type as that of the hardware device and providing the data to the virtual device includes:

[0062] Determine the data acquisition method that matches the data source method configured by the application functional component;

[0063] According to the data acquisition method, device data having the same data type as that of the hardware device is acquired and provided to the virtual device.

[0064] In the embodiment of the present application, for different application function components, the data acquisition methods adopted can be the same or different. Among them, for the application function components that need to be analyzed for exceptions, first determine the data source method of the device simulator configuration corresponding to the application function component. Exemplarily, taking a certain device simulator as an example, the device simulator indicates the data source method of the application function component by the value of the _original attribute corresponding to different application function components, wherein when the _original attribute value is 0, it indicates an unknown source, when the _original attribute value is 1, it indicates terminal source data, when the _original attribute value is 2, it indicates network source data, and when the _original attribute value is 3, it indicates virtual data generated by the hook. Among them, Hook is a hook function that executes a specific function written before / after the execution of an object function to implement functions such as intercepting information and changing the execution flow of a function. For example, a hook function that executes a parameter interception function before the execution of a certain object function can intercept the input parameters of the object function. For example, a hook function that executes a return value interception function after the execution of a certain object function can intercept the return value of the object function, and so on.

[0065] Correspondingly, for application functional components that require abnormal analysis, a data acquisition method that matches the data source method of the application functional component configured in the device simulator is determined, and device data with the same data type as the hardware device is obtained and provided to the virtual device according to the determined data acquisition method.

[0066] Optionally, in one embodiment, obtaining device data having the same data type as that of the hardware device and providing the data to the virtual device according to the data acquisition method includes:

[0067] If the determined data acquisition method is the first data acquisition method, device data having the same data type as the hardware device is acquired from a local hardware device having the same device type as the hardware device and provided to the virtual device; or

[0068] If the determined data acquisition method is the second data acquisition method, the state machine of the corresponding physical device is started through the virtual device, and device data of the same data type as the hardware device is obtained based on the state machine and provided to the virtual device; or

[0069] If the determined data acquisition method is the third data acquisition method, device data with the same data type as the hardware device is obtained from a remote physical device having the same device type and system version as the physical device and provided to the virtual device.

[0070] In the embodiments of this application, please refer to the reference Figure 1d, for different data source methods configured by the device simulator, corresponding data acquisition methods are provided to provide device data to the virtual device created by the device simulator for abnormality analysis.

[0071] Among them, when the data source mode configured by the device simulator is an unknown source, the data acquisition mode is determined to be the first data acquisition mode. Accordingly, when the data acquisition mode is determined to be the first data acquisition mode, the device data of the corresponding application functional component is obtained from the local hardware device. The local hardware device is of the same device type as the hardware device related to the abnormal operation event on the target physical device, that is, the device data obtained from the local hardware device is device data of the same data type as the hardware device related to the abnormal operation event on the target physical device. For example, assuming that the application functional component that needs to be analyzed for abnormality has an abnormal operation event related to the positioning device on the target physical device on which it is running, it is necessary to obtain positioning data for debugging through the virtual device. For example, taking the electronic device that executes the abnormality analysis method provided by this application as a macOS terminal as an example, you can first create a macOS application project, then import the corresponding native framework CoreLocation, and comply with the corresponding positioning protocol, then create a positioning instance, request positioning data from the local positioning device, and implement the reception of positioning data in the protocol method to obtain positioning data from the local positioning device of the macOS terminal.

[0072] When the data source mode configured by the device simulator is generated by hook, the data acquisition mode is determined to be the second data acquisition mode. Accordingly, when the data acquisition mode is determined to be the second data acquisition mode, the state machine of the corresponding target entity device is started through the virtual device, and the device data with the same data type as the hardware device is obtained based on the state machine and provided to the virtual device. It should be noted that the state machine is the state machine of the real machine environment of the corresponding target entity device. The state machine here can be regarded as a context environment, and the data in the context environment can be obtained. For example, assuming that the application function component that needs to be analyzed for abnormality has an abnormal operation event related to the camera device on the target entity device on which it runs, it is necessary to obtain image data for debugging through the virtual device. For example, the virtual device created by the device simulator has a picture folder. According to the path of this picture folder, the image data in the folder can be directly obtained. Then, the function that accesses the picture folder can be hooked to obtain the path of the picture folder, and the image data in the picture folder can be directly obtained according to the path of the picture folder.

[0073] When the data source mode configured by the device simulator is a network source, the data acquisition mode is determined to be the third data acquisition mode. Accordingly, when the data acquisition mode is determined to be the third data acquisition mode, the device data of the same data type as the hardware device related to the abnormal operation event is obtained from a remote entity device whose device type and system version are the same as those of the target entity device through a network (which can be a wired network or a wireless network) and whose device type and system version are the same as those of the target entity device, and is provided to the virtual device. For example, assuming that an application function component that needs to be analyzed for abnormality has an abnormal operation event related to the Bluetooth device on the target entity device on which it is running, it is necessary to obtain Bluetooth data for debugging through the virtual device. For example, a data connection can be established with a remote entity device (which can be a private cloud real device or a public cloud real device, and there is no specific limitation here) through a network, and then Bluetooth data can be obtained from the Bluetooth device of the remote entity device based on the established data connection.

[0074] In 150 , debugging data of the function to be debugged during the debugging process is obtained, and the abnormal cause of the abnormal operation event is determined according to the debugging data.

[0075] In the embodiment of the present application, debugging data of the function to be debugged during the debugging process is further obtained. According to the configured exception analysis strategy, the exception analysis is performed based on the obtained debugging data to determine the cause of the abnormal operation event. For example, the function to be debugged that has an exception can be located and repaired accordingly to eliminate the exception.

[0076] It should be noted that this embodiment does not impose any specific restrictions on the configuration of the anomaly analysis strategy, and designers in this field can configure it according to actual needs based on expert knowledge.

[0077] Optionally, in one embodiment, obtaining debugging data during the debugging process includes:

[0078] Execution result data of different to-be-debugged functions that have an execution dependency relationship are obtained, and the obtained execution result data are used as debugging data.

[0079] It is understandable that there are execution dependencies between different functions. For example, the execution of a function depends on the execution result of another function, and the execution result of the function affects the execution of other functions. In other words, the occurrence of an abnormal operation event may be caused by the action of a series of functions with an execution dependency relationship. Therefore, in the embodiment of the present application, in order to accurately locate the function to be debugged that causes the abnormal operation event, the debug data obtained includes the execution result data of different functions to be debugged with an execution dependency relationship. The existence of a dependency relationship means that the execution of one function depends on the execution result of another function. For example, a sub-function of an application functional component is implemented by three functions, namely function D, function E, and function F. Function D processes the original data to obtain first process data, function E processes the first process data to obtain second process data, and function F processes the second process data to obtain final result data. The execution of function E depends on the execution result of function D, and the execution of function F depends on the execution result of function E. Function D, function E, and function F are functions with an execution dependency relationship.

[0080] Optionally, in one embodiment, to improve the efficiency of exception analysis, the exception data during the debugging process is tracked and debug data is obtained in a targeted manner. In addition, the exception is isolated in the debugging process. Before obtaining the execution result data of different to-be-debugged functions with execution dependencies, the following is also included:

[0081] In response to a data anomaly in the execution result data of the function to be debugged, creating a target call object that complies with the calling rule of the abnormal function to be debugged;

[0082] Replace the current call object of the exception function to be debugged with the target call object;

[0083] Obtain the execution result data of different functions to be debugged that have execution dependencies, including:

[0084] First execution result data of the abnormal function to be debugged is obtained, and second execution result data of other functions to be debugged that have an execution dependency relationship with the abnormal function to be debugged is obtained.

[0085] Among them, data exceptions can be captured by symbolic breakpoints. Different from conventional breakpoints, symbolic breakpoints can set breakpoints for a certain function and suspend execution. In other words, symbolic breakpoints are breakpoints for specific functions. In the embodiment of the present application, symbolic breakpoints are set for the function to be debugged to realize exception capture, which is not described in detail here.

[0086] When a data anomaly is detected in the execution result data of a function to be debugged, the function to be debugged with the data anomaly is marked as an abnormal function to be debugged. In response to the data anomaly, a call object that complies with the call rules of the abnormal function to be debugged is created and recorded as the target call object. The current call object of the abnormal function to be debugged is then replaced with the target call object, thereby isolating the anomaly during the debugging process. The call rules include, but are not limited to, the call objects indicating the permitted function calls and the calling method.

[0087] For example, please refer to Figure 1e After capturing the data exception by means of symbolic breakpoints, a target calling object CP0 is created that complies with the calling rules of the function to be debugged with the data exception. The current calling object CP1 that calls the function to be debugged with the exception is determined by means of hooking, and the CP1 object address is replaced with the CP0 object address, and the created CP0 object is set in the transfer parameter of the function to be debugged with the exception.

[0088] It should be noted that the execution of a function is inseparable from the call stack, which is also called the call stack. It is a space for storing the function's local variables, parameters, return values ​​and other data when the function is running. In the embodiment of the present application, the transfer process of the function to be debugged in the call stack is controlled, wherein different processing methods are adopted according to the data type of the execution result data of the function to be debugged. Among them, for a function to be debugged, if the execution result data of the function to be debugged is used as a function parameter, the input parameters of the network request class are encrypted according to the configured encryption method and written to the call stack, so that the function parameters are encoded when they are passed to the network sending class; if the execution result data of the function to be debugged is used as a return value, the execution result data is encrypted according to the configured encryption method and written to the call stack, and is stored locally in a persistent manner. For example, a local persistent storage method such as a database, archive, file, key-value pair, etc. can be used. There is no specific limitation on the data encryption method here, and it can be selected by those skilled in the art according to actual needs.

[0089] In the embodiment of the present application, the execution result data with data anomalies is used as the analysis object, and the execution result data with data anomalies is obtained and recorded as the first execution result data. In addition, the execution result data of other to-be-debugged functions that have an execution dependency relationship with the abnormal to-be-debugged function is also obtained and recorded as the second execution result data. As described above, the execution result data of the function is encrypted when it is written to the call stack, that is, the obtained first execution result data and the second execution result data are encrypted. They are decrypted according to the corresponding decryption method, and the decrypted first execution result data and the second execution result data are used as debugging data, thereby achieving tracking of the abnormal data.

[0090] Based on the decrypted debug data and the configured exception analysis strategy, the system detects the call stack that caused the abnormal operation event. The corresponding function to be debugged in that call stack is identified as the function that caused the abnormal operation event and is recorded in the debug log. Based on this debug log, the relevant developer can determine the function that caused the abnormal operation event in the application functional component and fix it accordingly to prevent the abnormal operation event from occurring again.

[0091] Optionally, in one embodiment, before determining the target physical device on which the application functional component requiring abnormality analysis is running, the method further includes:

[0092] Identify the target function of the hardware device of the target physical device in the application functional component;

[0093] Mark the identified target function as a function to be debugged and generate a real device plug-in for the corresponding target physical device.

[0094] In an embodiment of the present application, an optional method for generating a real device plug-in is provided.

[0095] First, the function in the application functional component that calls the hardware device of the target physical device is identified, which is recorded as the target function. The call to the hardware device of the target physical device can be a direct call or an indirect call. After the target function in the application functional component that calls the hardware device of the target physical device is identified, the identified target function is further marked as a function to be debugged and encapsulated as a real-device plug-in corresponding to the target physical device.

[0096] For example, when generating a real-device plug-in for a target physical device, the target function identified as a function to be debugged can be encapsulated as a real-device plug-in for the target physical device using the corresponding debugging tool according to the system type of the target physical device and in accordance with the plug-in specification of the device simulator. For example, if the system type of the target physical device is Android, the ADB tool can be used to encapsulate the identified target function as a real-device plug-in for the target physical device. If the system type of the target physical device is iOS, the libiphone tool can be used to encapsulate the identified target function as a real-device plug-in for the target physical device.

[0097] Optionally, in one embodiment, identifying a target function in an application function component that calls a hardware device of a target entity device includes at least one of the following:

[0098] Obtaining a static library of a device architecture corresponding to the target physical device, and identifying, based on the static library, a target function in the application functional component that calls a hardware device of the target physical device;

[0099] Hooking the proxy method of calling the hardware device of the corresponding target physical device, and identifying the target function of calling the hardware device of the target physical device in the application functional component according to the function address after the hook;

[0100] Determine a configuration file of a hardware device corresponding to the target physical device, and identify a target function in the application function component that calls the hardware device of the target physical device based on the configuration file;

[0101] Detect device data of the hardware device externally input to the application function component, and identify the target function of the hardware device of the target entity device in the application function component based on the device data.

[0102] Please refer to Figure 1f The embodiment of the present application provides a variety of optional function identification methods, which can identify the target function of the hardware device of the target entity device in the application function component by at least one of the multiple function identification methods provided, and generate a real machine plug-in corresponding to the target entity device accordingly.

[0103] First, the component package of the application functional component is checked for architecture. The real machine architecture that the component can support can be extracted through the lipo related commands, and then the static library of the device architecture of the corresponding target entity device is obtained. For example, static libraries of different architectures such as ARM64, X86-64, ARM-V7 need to use different environments to run. Among them, the library is a written, reusable function code for use. In essence, the library is the binary form of the function, which can be loaded into memory and executed by the operating system. There are two types of libraries: static libraries and dynamic libraries. The static library involved in this application is called a static library because during the linking stage, the binary target file generated by the assembly is linked and packaged into the executable file together with the referenced library, so the corresponding linking method is called static connection. After obtaining the static library of the device architecture of the corresponding target entity device, the functions in the static library can be output through the nm command and stored in a temporary folder, and then the target function of the hardware device of the target entity device can be identified from it by static scanning.

[0104] Secondly, if the developer of the application functional component has performed operations such as obfuscation and encryption on the functions therein, the functions therein cannot be directly identified and need to be identified during their runtime. Among them, the target function is identified by hooking the function that calls the proxy method of the hardware device corresponding to the target entity device. Taking positioning as an example, it mainly includes two native methods: startUpdatingLocation (the system starts to obtain the geographic location) and didUpdateLocations (the location information is obtained and the longitude and latitude are generated). The +load method is used to detect the addresses of the startUpdatingLocation method and the didUpdateLocations method. According to the detected method address, the function that calls the startUpdatingLocation method and the didUpdateLocations method is hooked, and the function corresponding to the function address obtained by the hook is identified as the target function, thereby realizing the identification of the target function when the function is obfuscated, encrypted and other interference operations are performed.

[0105] Third, by scanning for configuration files corresponding to the hardware components of the target physical device, the target function that calls the hardware components of the target physical device is identified. For example, if an application component with bank card or face recognition needs to call the camera capability, the function corresponding to the configuration file that calls or enables the capability is identified as the target function.

[0106] Fourthly, a handle class can be established to detect the device data of the hardware device of the target physical device inputted by the application functional component, and the function inputted with the device data and the function with which it has an execution dependency relationship can be identified as the target function. For example, in some e-commerce components, it is necessary to recommend products based on location information. Then, the function in the e-commerce component that directly inputs the location information and other functions with which it has an execution dependency relationship can be identified as the target function. Among them, the handle class, also known as a smart pointer, is a class that stores pointers to dynamically allocated objects. Those skilled in the art can establish a handle class according to actual needs to realize the detection of external device data.

[0107] As can be seen from the above, the abnormality analysis solution provided by the present application determines the physical device on which the application function component that needs to be analyzed for abnormality is running, and the application function component has an abnormal operation event related to the hardware device of the physical device; creates a virtual device corresponding to the physical device through a device simulator, and the device model and system version of the virtual device are the same as the device model and system version of the physical device; loads a pre-generated real-machine plug-in corresponding to the physical device through the device simulator, and the real-machine plug-in includes the function to be debugged of the corresponding hardware device in the application function component; obtains device data of the same data type as the hardware device, and debugs the function to be debugged through the virtual device based on the abnormal operation event; obtains debugging data of the function to be debugged during the debugging process, and determines the abnormal cause of the abnormal operation event based on the debugging data. In this way, in addition to the simulation capability of the simulator's own software environment, by obtaining device data of the same data type as the hardware device on the physical device and providing it to the virtual device, the hardware environment of the physical device can be constructed, so that the function to be debugged can be debugged to reproduce the abnormal operation event under the same software and hardware environment as the simulated physical device, and then the abnormal cause of the abnormal operation event can be determined using the debugging data during the debugging process.

[0108] Please refer to Figure 2 Taking the execution subject of the abnormality analysis method provided in this application as an electronic device as an example, the process of the abnormality analysis method can also be as follows:

[0109] In 210 , in response to an abnormal operation event of the application function component being associated with a hardware device of the physical device, the electronic device identifies a target function of the application function component that calls the hardware device.

[0110] Application components are programmable, reusable, typically self-contained, and language-independent software units that can be easily used to build applications. For example, an instant messaging application might include components for chat, address book, scan, and shake, among others.

[0111] It is understandable that during the operation of an application, its application functional components will inevitably encounter various anomalies. For example, taking the application functional component that implements the scan function as an example, this application functional component needs to call the camera to collect image data, and then analyze the image data to obtain the analysis results. Anomalies may occur in each link of the process from acquiring image data to analyzing the analysis results, causing the scan function to fail. This application aims to analyze the anomalies of these application functional components that have abnormal operation events related to the hardware components of the physical device and determine the corresponding causes of the anomalies.

[0112] For example, consider an instant messaging app installed on a physical device. This app includes an application component that uses data from a gyroscope and a positioning device to implement a "shake" function. If the "shake" function of this application component fails, this application component can be identified as requiring an exception analysis. The function within this application component that calls the gyroscope and positioning device is identified and recorded as the target function. The call to the physical device's hardware components can be either direct or indirect.

[0113] The embodiment of the present application provides a plurality of optional function identification methods, and the target function of the hardware device of the physical device that calls the application function component can be identified by at least one of the plurality of function identification methods provided.

[0114] First, the electronic device performs an architecture check on the component package of the application function component. It can extract the real machine architecture that the component can support through the lipo related command, and then obtain the static library of the device architecture corresponding to the target entity device. For example, static libraries of different architectures such as ARM64, X86-64, ARM-V7 need to use different environments to run. Among them, the library is a written, usable, reusable function code. In essence, the library is the binary form of the function, which can be loaded into memory and executed by the operating system. There are two types of libraries: static libraries and dynamic libraries. The static library involved in this application is called a static library because during the linking stage, the binary target file generated by the assembly is linked and packaged into the executable file together with the referenced library, so the corresponding linking method is called static connection. After obtaining the static library of the device architecture corresponding to the target entity device, the electronic device can output the functions in the static library through the nm command and store them in a temporary folder, and then identify the target function of the hardware device that calls the target entity device through static scanning.

[0115] Secondly, if the developer of the application functional component has performed operations such as obfuscation and encryption on the functions therein, the electronic device cannot directly identify the functions therein and needs to identify them during its operation. Among them, the electronic device identifies the target function by hooking the function that calls the proxy method of the hardware device corresponding to the target entity device. Taking positioning as an example, it mainly includes two native methods: startUpdatingLocation (the system starts to obtain the geographic location) and didUpdateLocations (the location information is obtained and the longitude and latitude are generated). The electronic device uses the +load method to detect the addresses of the startUpdatingLocation method and the didUpdateLocations method. According to the detected method address, the function that calls the startUpdatingLocation method and the didUpdateLocations method is hooked, and the function corresponding to the function address obtained by the hook is identified as the target function, thereby realizing the identification of the target function when the function is obfuscated, encrypted and other interference operations are performed.

[0116] Third, the electronic device scans for configuration files corresponding to the physical device's hardware components to identify whether there is a target function that calls the physical device's hardware components. For example, if an application component with bank card or facial recognition needs to call the camera's capabilities, the function corresponding to the configuration file that calls or enables these capabilities will be identified as the target function.

[0117] Fourth, electronic devices can establish a handle class to detect the device data of the hardware devices of the physical device input from the external application function component, and identify the function that inputs the device data and the functions that have execution dependencies as target functions. For example, in some e-commerce components, it is necessary to recommend products based on location information. Then, the function in the e-commerce component that directly inputs the location information and other functions that have execution dependencies with the function can be identified as target functions. Among them, the handle class, also known as a smart pointer, is a class that stores pointers to dynamically allocated objects. Those skilled in the art can establish a handle class according to actual needs to realize the detection of external device data.

[0118] In 220 , the electronic device uses the target function as a function to be debugged and generates a real device plug-in corresponding to the physical device.

[0119] As described above, after identifying the target function that calls the hardware device in the application functional component, the electronic device further uses the identified target function as a function to be debugged and generates a real device plug-in corresponding to the physical device.

[0120] When generating a real-device plug-in for a corresponding physical device, the electronic device can, based on the physical device's system type, use the corresponding debugging tool and, in accordance with the device simulator's plug-in specifications, encapsulate the identified target function as a function to be debugged into a real-device plug-in for the corresponding physical device. For example, if the physical device's system type is Android, the electronic device can use the ADB tool to encapsulate the identified target function into a real-device plug-in for the corresponding physical device. If the physical device's system type is iOS, the electronic device can use the libiphone tool to encapsulate the identified target function into a real-device plug-in for the corresponding physical device.

[0121] In 230 , the electronic device creates a virtual device corresponding to the physical device through a device simulator. The device model and system version of the virtual device are the same as those of the physical device.

[0122] In 240 , the electronic device loads the real device plug-in corresponding to the physical device through the device simulator.

[0123] The specific device simulator is not specifically limited here. It is limited to the architecture and system simulation capabilities of the physical device. Those skilled in the art can select a device simulator based on their actual needs. For example, the electronic device may be an X86-based desktop computer. This desktop computer can use the device simulator to simulate a physical mobile device with an ARM architecture and corresponding system version, thereby creating a corresponding virtual mobile device.

[0124] In an embodiment of the present application, after generating a real device plug-in corresponding to the physical device, the electronic device further determines the device model and system version of the physical device, and then creates a virtual device with the same device model and system version as the physical device according to the device model and system version of the physical device. For example, if the device model of the physical device running the application function component that needs to be analyzed for anomalies is "xphone14" and the system version is "os16.4", the electronic device will correspondingly create a virtual device with the device model "xphone14" and the system version "os16.4" by running a device simulator to simulate the physical device.

[0125] As described above, after creating a virtual device corresponding to the physical device through the device simulator, the electronic device further loads a real device plug-in corresponding to the physical device through the device simulator.

[0126] In 250 , the electronic device determines a data acquisition method that matches the data source method configured by the application functional component.

[0127] In 260 , the electronic device obtains device data having the same data type as that of the hardware device according to the determined data acquisition method and provides the data to the virtual device.

[0128] In 270 , the electronic device debugs the function to be debugged using the device data through the virtual device according to the abnormal operation event.

[0129] In the embodiment of the present application, device data of the same data type as the hardware device related to the abnormal operation event on the physical device is also obtained, thereby realizing the construction of the hardware environment of the physical device. For example, assuming that the abnormal operation event is an abnormal operation event related to a positioning device, then the device data of the same data type as the positioning device is obtained, that is, positioning data; assuming that the abnormal operation event is an abnormal operation event related to a motion sensor such as a gyroscope, then the device data of the same data type as the motion sensor is obtained, that is, motion data; assuming that the abnormal operation event is an abnormal operation event related to a camera, then the device data of the same data type as the camera is obtained, that is, image data.

[0130] It should be noted that for different application function components, the data acquisition methods used can be the same or different. Among them, for application function components that need to be analyzed for exceptions, first determine the data source method of the device simulator configuration corresponding to the application function component. Exemplarily, taking a certain device simulator as an example, the device simulator indicates the data source method of the application function component by the value of the _original attribute corresponding to different application function components, wherein, when the _original attribute value is 0, it indicates an unknown source, when the _original attribute value is 1, it indicates terminal source data, when the _original attribute value is 2, it indicates network source data, and when the _original attribute value is 3, it indicates virtual data generated by the hook.

[0131] Correspondingly, for application functional components that require abnormal analysis, the electronic device determines a data acquisition method that matches the data source method of the application functional component configured in the device simulator, and obtains device data with the same data type as the hardware device in accordance with the determined data acquisition method and provides it to the virtual device.

[0132] Among them, when the data source mode configured by the device simulator is an unknown source, the electronic device determines that the data acquisition mode is the first data acquisition mode. Accordingly, when determining that the data acquisition mode is the first data acquisition mode, the electronic device obtains the device data of the corresponding application function component from the local hardware device. The local hardware device is of the same device type as the hardware device related to the abnormal operation event on the physical device, that is, the device data obtained from the local hardware device is device data of the same data type as the hardware device related to the abnormal operation event on the physical device. Exemplarily, assuming that the application function component that needs to be analyzed for abnormality has an abnormal operation event related to the positioning device on the physical device on which it runs, it is necessary to obtain positioning data for debugging through the virtual device. For example, taking the electronic device as a macOS terminal, you can first create a macOS application project, then import the corresponding native framework CoreLocation, and comply with the corresponding positioning protocol, and then create a positioning instance, request positioning data from the local positioning device, and implement the reception of positioning data in the protocol method, so as to obtain positioning data from the local positioning device of the macOS terminal.

[0133] When the data source mode configured by the device simulator is generated by hook, the electronic device determines that the data acquisition mode is the second data acquisition mode. Accordingly, when the data acquisition mode is determined to be the second data acquisition mode, the electronic device starts the state machine of the corresponding target physical device through the virtual device, and obtains the device data of the same data type as the hardware device based on the state machine and provides it to the virtual device. It should be noted that the state machine is the state machine of the real machine environment of the corresponding physical device. The state machine here can be regarded as a context environment, and the data in the context environment can be obtained. For example, assuming that the application function component that needs to be analyzed for abnormality has an abnormal operation event related to the camera device on the physical device on which it runs, it is necessary to obtain image data for debugging through the virtual device. For example, the virtual device created by the device simulator has a picture folder. According to the path of this picture folder, the image data in the folder can be directly obtained. Then, the function that accesses the picture folder can be hooked to obtain the path of the picture folder, and the image data in the picture folder can be directly obtained according to the path of the picture folder.

[0134] When the data source mode configured by the device simulator is a network source, the electronic device determines that the data acquisition mode is the third data acquisition mode. Accordingly, when determining that the data acquisition mode is the third data acquisition mode, the electronic device obtains device data of the same data type as the hardware device related to the abnormal operation event from a remote entity device whose device type and system version are the same as those of the entity device through a network (which can be a wired network or a wireless network), and provides it to the virtual device. For example, assuming that an application function component that needs to be analyzed for abnormality has an abnormal operation event related to the Bluetooth device on the entity device on which it runs, it is necessary to obtain Bluetooth data for debugging through the virtual device. For example, a data connection can be established with a remote entity device (which can be a private cloud real device or a public cloud real device, and there is no specific limitation here) through the network, and then Bluetooth data can be obtained from the Bluetooth device of the remote entity device based on the established data connection.

[0135] As mentioned above, after obtaining device data with the same data type as the hardware device, the obtained device data is provided to the virtual device created by the device simulator, and further abnormal operation events occurring in the application function components for abnormal analysis as needed are performed. The virtual device created by the device simulator uses the obtained device data to debug the function to be debugged to reproduce the abnormal operation event.

[0136] It should be noted that the acquired device data can be provided to the virtual device created by the device simulator using a process communication method. Process communication methods include, but are not limited to, shared memory mode, message passing mode, and shared file mode, and can be selected by those skilled in the art based on actual needs.

[0137] In 280 , the electronic device obtains debugging data of the function to be debugged during the debugging process, and determines the abnormal cause of the abnormal operation event according to the debugging data.

[0138] In the embodiment of the present application, abnormal data in the debugging process is tracked and the abnormality is isolated in the debugging process. Among them, data abnormalities can be captured by symbolic breakpoints. The specific configuration can be made by those skilled in the art according to actual needs and will not be described here.

[0139] When the execution result data of a function to be debugged contains a data anomaly, the function to be debugged with the data anomaly is recorded as an abnormal function to be debugged. In response to the data anomaly, a call object that complies with the call rules of the abnormal function to be debugged is created and recorded as a target call object. The current call object of the abnormal function to be debugged is replaced with the target call object, thereby isolating the anomaly during the debugging process. Furthermore, the execution result data with the data anomaly is used as the analysis object, and the execution result data with the data anomaly is obtained and recorded as the first execution result data. In addition, the execution result data of other functions to be debugged that have an execution dependency relationship with the abnormal function to be debugged is also obtained and recorded as the second execution result data. The obtained first and second execution result data are used as debugging data to track the abnormal data. The calling rules include, but are not limited to, the calling objects used to indicate that the function is allowed to be called, as well as the calling method.

[0140] As described above, the electronic device performs an anomaly analysis based on the acquired debugging data according to the configured anomaly analysis strategy to determine the cause of the abnormal operation event. The configuration of the anomaly analysis strategy is not specifically limited here and can be configured by designers in this field based on their expert knowledge and actual needs.

[0141] To facilitate better implementation of the above-mentioned abnormality analysis method for servers, the present application also provides a corresponding abnormality analysis device. The meanings of the terms are the same as those in the above-mentioned abnormality analysis method for servers. For specific implementation details, please refer to the description in the above method embodiment.

[0142] Please refer to Figure 3 , Figure 3 This is a structural diagram of an abnormality analysis device provided in an embodiment of the present application. The abnormality analysis device may include a device determination module 310, a device simulation module 320, a plug-in loading module 330, a function debugging module 340 and an abnormality analysis module 350, wherein:

[0143] The device determination module 310 is used to determine the target physical device on which the application function component that needs to be analyzed for abnormality is running, and the application function component has an abnormal operation event related to the hardware device of the target physical device;

[0144] The device simulation module 320 is used to create a virtual device corresponding to the target physical device through a device simulator, wherein the device model and system version of the virtual device are the same as those of the target physical device;

[0145] A plug-in loading module 330 is configured to load a pre-generated real-device plug-in corresponding to a target physical device through a device simulator. The real-device plug-in includes a function to be debugged of an application functional component. The function to be debugged is a function that has a calling relationship with a hardware device.

[0146] The function debugging module 340 is used to obtain device data of the same data type as the hardware device and provide it to the virtual device, and debug the function to be debugged by using the device data through the virtual device according to the abnormal operation event;

[0147] The exception analysis module 350 is used to obtain debugging data of the function to be debugged during the debugging process, and determine the abnormal cause of the abnormal operation event based on the debugging data.

[0148] Optionally, in one embodiment, the function debugging module 340 is used to determine a data acquisition method that matches the data source method configured by the application functional component; and according to the data acquisition method, obtain device data with the same data type as the hardware device and provide it to the virtual device.

[0149] Optionally, in one embodiment, the function debugging module 340 is used to, if the determined data acquisition method is the first data acquisition method, obtain device data of the same data type as the hardware device from a local hardware device of the same device type as the hardware device and provide it to the virtual device; or, if the determined data acquisition method is the second data acquisition method, start the state machine of the corresponding target physical device through the virtual device, and obtain device data of the same data type as the hardware device based on the state machine and provide it to the virtual device; or, if the determined data acquisition method is the third data acquisition method, obtain device data of the same data type as the hardware device from a remote physical device whose device type and system version are the same as those of the target physical device and provide it to the virtual device.

[0150] Optionally, in one embodiment, the exception analysis module 350 is used to create a target calling object that complies with the calling rules of the abnormal function to be debugged in response to a data exception in the execution result data of the function to be debugged; and replace the current calling object of the abnormal function to be debugged with the target calling object; and obtain the first execution result data of the abnormal function to be debugged, and obtain the second execution result data of other functions to be debugged that have an execution dependency relationship with the abnormal function to be debugged; and use the first execution result data and the second execution result data as debugging data.

[0151] Optionally, in one embodiment, the exception analysis device provided by the present application also includes a plug-in generation module for identifying the target function of the hardware device that calls the target entity device in the application functional component; and marking the identified target function as a function to be debugged, and generating a real machine plug-in corresponding to the target entity device based on the function to be debugged.

[0152] Optionally, in one embodiment, the plug-in generation module is used to encapsulate the function to be debugged into a real machine plug-in corresponding to the target physical device by using a debugging tool that matches the system type of the target physical device.

[0153] Optionally, in one embodiment, the plug-in generation module is used to perform at least one of the following: obtaining a static library of the device architecture corresponding to the target entity device, and identifying the target function of the hardware device of the target entity device in the application function component based on the static library; calling the proxy method of the hardware device of the corresponding target entity device to hook, and identifying the target function of the hardware device of the target entity device in the application function component based on the function address after the hook; determining the configuration file of the hardware device of the corresponding target entity device, and identifying the target function of the hardware device of the target entity device in the application function component based on the configuration file; detecting the device data of the hardware device input from the outside of the application function component, and identifying the target function of the hardware device of the target entity device in the application function component based on the device data.

[0154] The specific implementation of each of the above modules can be found in the previous embodiments and will not be described again here.

[0155] An embodiment of the present application also provides an electronic device, including a memory and a processor, wherein the processor is configured to execute the steps of the anomaly analysis method suitable for the server provided in the above embodiment, or execute the steps of the anomaly analysis method suitable for the client provided in the above embodiment, by calling a computer program stored in the memory.

[0156] Please refer to Figure 4 , Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0157] The electronic device may include one or more processors 101, one or more computer-readable storage media memories 102, a power supply 103, an input unit 104, and other components. It will be understood by those skilled in the art that Figure 4 The electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange components differently.

[0158] Processor 101 is the control center of the electronic device. It connects all parts of the electronic device using various interfaces and circuits. It executes software programs and / or modules stored in memory 102 and accesses data stored in memory 102 to perform various functions of the electronic device and process data. Optionally, processor 101 may include one or more processing cores. Alternatively, processor 101 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 101.

[0159] The memory 102 can be used to store software programs and modules. The processor 101 executes various functional applications and data processing by running the software programs and modules stored in the memory 102. The memory 102 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 102 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 102 may also include a memory controller to provide the processor 101 with access to the memory 102.

[0160] The electronic device also includes a power supply 103 for supplying power to various components. Optionally, the power supply 103 can be logically connected to the processor 101 via a power management system, thereby enabling the power management system to manage charging, discharging, and power consumption. The power supply 103 can also include one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and other arbitrary components.

[0161] The electronic device may further include an input unit 104, which may be configured to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0162] Although not shown, the electronic device may also include a display unit, an image acquisition component, etc., which will not be described in detail here. Specifically in this embodiment, the processor 101 loads the executable code corresponding to one or more computer programs into the memory 102, and the processor 101 executes the steps of the abnormality analysis method provided in this application, such as:

[0163] Determine the target physical device on which the application functional component requiring abnormal analysis is running, where the application functional component has an abnormal operation event related to the hardware device of the target physical device;

[0164] Create a virtual device corresponding to the target physical device through the device simulator. The device model and system version of the virtual device are the same as those of the target physical device.

[0165] Loading a pre-generated real device plug-in corresponding to the target physical device through the device simulator, the real device plug-in includes the to-be-debugged function of the application functional component, and the to-be-debugged function is a function that has a calling relationship with the hardware device;

[0166] Obtaining device data of the same data type as the hardware device and providing it to the virtual device, and debugging the function to be debugged by using the device data through the virtual device according to the abnormal operation event;

[0167] Obtain debugging data of the function to be debugged during the debugging process, and determine the abnormal cause of the abnormal operation event based on the debugging data.

[0168] It should be noted that the electronic device provided in the embodiment of the present application and the abnormality analysis method in the above embodiment have the same concept, and the specific implementation process is detailed in the above related embodiments and will not be repeated here.

[0169] The present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program stored thereon is executed on a processor of an electronic device provided in an embodiment of the present application, the processor of the electronic device implements the steps of the anomaly analysis method provided in the present application. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0170] The present application also provides a computer program product, which includes a computer program. When the computer program is executed on the processor of the electronic device provided in the embodiment of the present application, the processor of the electronic device implements the steps in the abnormality analysis method provided in the present application.

[0171] The above is a detailed introduction to the anomaly analysis method, anomaly analysis device, electronic device, computer-readable storage medium and computer program product provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core ideas. At the same time, for technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

[0172] It should be noted that when the above embodiments of this application are applied to specific products or technologies, the relevant user data is involved, and the user's permission or consent must be obtained, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A method for abnormality analysis, characterized in that: include: Determine a target physical device on which an application functional component requiring abnormality analysis is running, wherein the application functional component has an abnormal operation event related to a hardware device of the target physical device; Creating a virtual device corresponding to the target physical device through a device simulator, wherein the device model and system version of the virtual device are the same as those of the target physical device; Loading a pre-generated real-machine plug-in corresponding to the target physical device through the device simulator, wherein the real-machine plug-in includes a function to be debugged of the application functional component, and the function to be debugged is a function that has a calling relationship with the hardware device; Acquire device data of the same data type as the hardware device and provide it to the virtual device, and debug the function to be debugged by using the device data through the virtual device according to the abnormal operation event; Debugging data of the function to be debugged during the debugging process is acquired, and the abnormal cause of the abnormal operation event is determined according to the debugging data.

2. The abnormality analysis method according to claim 1, characterized in that: The acquiring device data having the same data type as that of the hardware device and providing the data to the virtual device includes: Determining a data acquisition method that matches the data source method configured by the application functional component; According to the data acquisition method, device data having the same data type as that of the hardware device is acquired and provided to the virtual device.

3. The abnormality analysis method according to claim 2, characterized in that: The step of obtaining device data having the same data type as that of the hardware device and providing the data to the virtual device according to the data obtaining method includes: If the determined data acquisition method is the first data acquisition method, obtaining device data of the same data type as the hardware device from a local hardware device of the same device type as the hardware device and providing the data to the virtual device; or If the determined data acquisition method is the second data acquisition method, starting a state machine corresponding to the target physical device through the virtual device, and obtaining device data having the same data type as the hardware device based on the state machine and providing the data to the virtual device; or If the determined data acquisition method is the third data acquisition method, device data with the same data type as the hardware device is obtained from a remote entity device whose device type and system version are the same as those of the target entity device and provided to the virtual device.

4. The abnormality analysis method according to claim 1, characterized in that: Before obtaining the debugging data during the debugging process, the method further includes: In response to a data anomaly in the execution result data of the function to be debugged, creating a target call object that complies with the calling rule of the abnormal function to be debugged; Replacing the current calling object of the abnormal function to be debugged with the target calling object; The obtaining of debugging data during the debugging process includes: Acquire first execution result data of the abnormal function to be debugged, and acquire second execution result data of other functions to be debugged that have an execution dependency relationship with the abnormal function to be debugged; The first execution result data and the second execution result data are used as debugging data.

5. The abnormality analysis method according to claim 1, characterized in that: Before determining the target physical device running the application functional component requiring abnormality analysis, the method further includes: Identifying a target function in the application function component that calls a hardware device of the target physical device; The identified target function is marked as a function to be debugged, and a real device plug-in corresponding to the target physical device is generated according to the function to be debugged.

6. The abnormality analysis method according to claim 5, characterized in that: Generating a real device plug-in corresponding to the target physical device according to the function to be debugged includes: The function to be debugged is encapsulated as a real machine plug-in corresponding to the target physical device through a debugging tool that matches the system type of the target physical device.

7. The abnormality analysis method according to claim 6, characterized in that: The identifying the target function of the hardware device of the target entity device in the application functional component includes at least one of the following: Obtaining a static library corresponding to a device architecture of the target physical device, and identifying, based on the static library, a target function in the application functional component that calls a hardware device of the target physical device; Hooking a proxy method for calling a hardware device corresponding to the target physical device, and identifying a target function in the application function component that calls the hardware device of the target physical device according to a function address after the hook; Determine a configuration file of a hardware device corresponding to a target physical device, and identify, based on the configuration file, a target function in the application function component that calls the hardware device of the target physical device; Detect device data of the hardware device externally input to the application function component, and identify the target function of the hardware device of the target entity device in the application function component based on the device data.

8. An abnormality analysis device, characterized in that: include: A device determination module is used to determine a target physical device on which an application functional component requiring abnormality analysis is running, wherein the application functional component has an abnormal operation event related to a hardware device of the target physical device; A device simulation module, configured to create a virtual device corresponding to the target physical device through a device simulator, wherein the device model and system version of the virtual device are the same as those of the target physical device; a plug-in loading module, configured to load a pre-generated real-machine plug-in corresponding to the target physical device through the device simulator, wherein the real-machine plug-in includes a function to be debugged of the application functional component, and the function to be debugged is a function that has a calling relationship with the hardware device; a function debugging module, configured to obtain device data of the same data type as the hardware device and provide the data to the virtual device, and debug the function to be debugged by using the device data through the virtual device according to the abnormal operation event; The abnormality analysis module is used to obtain the debugging data of the function to be debugged during the debugging process, and determine the abnormal cause of the abnormal operation event according to the debugging data.

9. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the steps of the abnormality analysis method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and the computer program is suitable for being executed by a processor to implement the steps in the abnormality analysis method according to any one of claims 1 to 7.

Images