Software dynamic analysis method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a software dynamic analysis method and device, computer equipment, a readable storage medium and a program product. The method comprises the following steps: carrying out online dynamic analysis on a real running state of software to be analyzed; the online dynamic analysis at least comprises performance analysis of hardware resources of the to-be-analyzed software; in response to the ending of the operation of the to-be-analyzed software, performing offline dynamic analysis on the obtained operation behavior of the to-be-analyzed software; the offline dynamic analysis at least comprises analysis of resource dump of different levels on the software to be analyzed, debugging tracking based on breakpoints and bottleneck analysis based on data flow directions. By adopting the method, the software analysis accuracy can be improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a software dynamic analysis method, apparatus, computer equipment, readable storage medium, and program product. Background Technology

[0002] With the development of software testing technology, software testing tools have emerged to evaluate software, including dynamic software analysis tools for implementing dynamic software analysis methods.

[0003] However, traditional software dynamic analysis tools and their corresponding methods do not have high accuracy in software analysis. Summary of the Invention

[0004] Therefore, it is necessary to provide a software dynamic analysis method, apparatus, computer equipment, readable storage medium, and program product that can improve the accuracy of software analysis in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a software dynamic analysis method, including:

[0006] The actual operating status of the software to be analyzed is analyzed online dynamically; the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed.

[0007] In response to the end of the operation of the software to be analyzed, an offline dynamic analysis is performed on the obtained running behavior of the software to be analyzed; the offline dynamic analysis includes at least the analysis of resource dumps of the software to be analyzed at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

[0008] In one embodiment, the online dynamic analysis of the actual operating status of the software to be analyzed includes:

[0009] Based on the memory and processor resources of the software under analysis during runtime, key hardware resources are identified and thread mapping is performed; the key hardware resources include at least shared memory resources.

[0010] The memory block usage information of the software under analysis during execution is obtained, and a memory allocation method is determined based on the memory block usage information; the memory allocation method includes releasing the memory blocks.

[0011] Performance bottlenecks are identified based on system architecture configuration files, and throughput detection and analysis are performed on each disk based on the actual load of each disk.

[0012] In one embodiment, the analysis of the software to be analyzed by performing resource dumps at different levels includes:

[0013] Receive resource dump files at different levels, and obtain dump file analysis logs based on the resource dump files; the different levels include kernel level, user level, and application thread level;

[0014] The dump file analysis logs were parsed to extract the basic characteristics of the crash;

[0015] Based on the basic crash characteristics, auxiliary crash characteristics are generated, and the resource dump file is analyzed based on the basic crash characteristics and the auxiliary crash characteristics.

[0016] In one embodiment, the step of performing breakpoint-based debugging and tracing on the software to be analyzed includes:

[0017] Breakpoints are set based on the software to be analyzed, causing the program of the software to be analyzed to execute in a preset step unit;

[0018] When the processor reaches the breakpoint, the program execution stops and is interrupted by the debugger;

[0019] In response to the program in the debugger completing debugging, the program resumes execution.

[0020] In one embodiment, the bottleneck analysis of the software to be analyzed based on data flow includes:

[0021] Obtain the data flow of the program in the software to be analyzed;

[0022] The location of the bottleneck is determined based on the system logs and the data flow;

[0023] The input required for the bottleneck analysis is obtained based on performance monitoring tools.

[0024] In one embodiment, the bottleneck analysis includes: analysis of hardware resource bottlenecks, analysis of application software bottlenecks, analysis of operating system bottlenecks, and analysis of network device bottlenecks.

[0025] Secondly, this application also provides a software dynamic analysis apparatus, comprising:

[0026] The online dynamic analysis module is used to perform online dynamic analysis of the actual operating status of the software to be analyzed; the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed.

[0027] The offline dynamic analysis module is used to perform offline dynamic analysis on the behavior of the software under analysis in response to the end of the software's operation; the offline dynamic analysis includes at least the analysis of resource dumps of the software under analysis at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

[0028] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0029] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0030] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0031] The aforementioned software dynamic analysis method, apparatus, computer equipment, readable storage medium, and program product perform online dynamic analysis of the actual operating state of the software to be analyzed; wherein the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed; and in response to the end of the operation of the software to be analyzed, perform offline dynamic analysis of the obtained operating behavior of the software to be analyzed; wherein the offline dynamic analysis includes at least the analysis of resource dumps of the software to be analyzed at different levels, breakpoint-based debugging and tracing, and bottleneck analysis based on data flow, thereby improving the accuracy of software analysis. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a flowchart illustrating a software dynamic analysis method in one embodiment;

[0034] Figure 2 This is a flowchart illustrating the steps of performing online dynamic analysis of the actual operating state of the software to be analyzed in one embodiment.

[0035] Figure 3 This is a system architecture diagram of a dynamic analysis tool using a software dynamic analysis method in one embodiment.

[0036] Figure 4 This is a structural block diagram of a software dynamic analysis device in one embodiment;

[0037] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0039] The terms "comprising" and "having," and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more. The term "and / or" as used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0040] Traditional software dynamic analysis methods and tools suffer from problems such as lack of support for new software forms, low analysis accuracy, and high analysis costs.

[0041] Based on the aforementioned traditional technologies, embodiments of this application provide a software dynamic analysis method. By developing automated and intelligent dynamic analysis tools for basic software based on this method, it supports hotspot analysis of hardware resources, memory perspective, resource throughput analysis, and dump analysis of various resources in both online and offline dynamic analysis modes. It also supports debugging tracing and bottleneck analysis at the kernel level, system level, runtime environment level, and application system level, aiming to solve the problems of traditional dynamic analysis tools such as lack of support for new software forms, low analysis accuracy, and large analysis overhead.

[0042] It should be noted that the beneficial effects or technical problems solved by the embodiments of this application are not limited to this one, but may also be other implicit or related problems. For details, please refer to the description of the embodiments below.

[0043] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0044] In one embodiment, such as Figure 1 As shown, a software dynamic analysis method is provided. This embodiment illustrates the method's application to a terminal, but it is understood that the method can also be applied to a server, and to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0045] Step 202: Perform online dynamic analysis on the actual operating status of the software to be analyzed; the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed.

[0046] Online dynamic analysis refers to analyzing the actual operating status of software during its operation. Its key technology is hardware resource performance analysis technology, and the software to be analyzed can be simply referred to as software.

[0047] Specifically, online dynamic analysis is performed on the actual operating status of the software to be analyzed, which includes at least the performance analysis of the hardware resources of the software to be analyzed.

[0048] For example, online dynamic analysis is performed on the actual operating status of the software under test, including computer system resources, memory status, and resource throughput, so as to accurately and comprehensively realize fault detection and online monitoring of the software under test from the hardware perspective.

[0049] Step 204: In response to the end of the operation of the software to be analyzed, perform offline dynamic analysis on the obtained running behavior of the software to be analyzed; the offline dynamic analysis includes at least the analysis of resource dumps of the software to be analyzed at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

[0050] Offline dynamic analysis refers to the analysis of recorded software behavior after the program has finished running. Its key technologies are resource dump analysis, debugging tracing, and bottleneck analysis. Bottleneck analysis refers to the analysis of performance bottlenecks.

[0051] Specifically, in response to the end of the operation of the software to be analyzed, the recorded behavior of the software to be analyzed is subjected to offline dynamic analysis. The offline dynamic analysis includes at least the analysis of resource dumps of the software to be analyzed at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

[0052] For example, by performing multi-faceted automatic offline dynamic analysis on the software to be analyzed, including resource dump analysis at different levels, breakpoint-based debugging tracing, and data flow-based bottleneck analysis, the resource dump-related files of the software to be analyzed can be analyzed efficiently and accurately, thereby achieving accurate debugging tracing and accurate analysis of the software's performance bottlenecks.

[0053] The aforementioned software dynamic analysis method involves online dynamic analysis of the actual operating state of the software under analysis; and offline dynamic analysis of the acquired operating behavior of the software under analysis in response to its completion. The online dynamic analysis includes at least performance analysis of the hardware resources of the software under analysis, while the offline dynamic analysis includes at least analysis of resource dumps at different levels, breakpoint-based debugging and tracing, and bottleneck analysis based on data flow. This method supports accurate analysis from multiple perspectives using both online and offline dynamic analysis methods, thereby achieving accurate analysis of the software under test, including hardware resources, resource dumps, and performance bottlenecks. It also enables accurate debugging and tracing, facilitating software maintenance and accurate debugging, and improving the accuracy of software dynamic analysis.

[0054] In one exemplary embodiment, such as Figure 2 As shown, step 202 involves performing online dynamic analysis of the actual operating status of the software to be analyzed, including steps 302 to 306. Wherein:

[0055] Step 302: Determine key hardware resources based on the memory and processor resources of the software under analysis during runtime, and perform thread mapping; key hardware resources include at least shared memory resources.

[0056] Hardware resources can refer to computer system resources such as CPU, memory, multi-level cache, hard disk, and network.

[0057] Specifically, online dynamic analysis of the actual operating status of the software being analyzed can include hardware resource hotspot analysis. Hardware resource hotspots refer to frequently accessed hardware resources. Hardware resource hotspot analysis involves analyzing data on frequently used hardware monitoring metrics at a given moment. Different hardware has different monitoring metrics, such as CPU utilization, memory utilization, network status, and application software operation. Hotspot analysis acquires and analyzes key computer hardware resource monitoring metrics at a specific moment, providing administrators with a dynamic view of hardware resource status, facilitating real-time monitoring and resource management, and ensuring stable and normal computer operation.

[0058] In analyzing hardware resource hotspots, the first step is to study the analysis and display of monitoring metrics. Different hardware has different monitoring metrics during program execution and resource scheduling. System resources are constantly changing, and the usage of different resources varies at different times. Hardware monitoring metrics often need to be extracted from the hardware's operating status. Based on the raw data of hardware resource status, we need to identify which resources are hotspots, process the data, and provide corresponding monitoring data analysis and display. Hardware monitoring content can refer to mainstream system monitoring software, such as iStatistica Pro for Mac and CleanMyMac for system resource management. Their monitoring metrics mainly include CPU utilization, memory utilization, network exchange speed, hard drive utilization, and app power consumption.

[0059] Furthermore, the management of shared resources needs to be studied. Compared to traditional single-processor systems, multi-chip processors significantly improve system throughput by providing computing resources that allow multiple threads to execute in parallel. To fully realize the potential of these powerful platforms, effectively managing the resources shared by these concurrently executing threads has become a critical issue. With the development of multi-chip processors, the management of shared resources has become a key issue in fully realizing their potential. To overcome the difficulties of managing multiple resources simultaneously using thread mapping, a good understanding of the interactions between various microarchitectural resources and thread characteristics is essential.

[0060] Furthermore, regarding shared resource management techniques in the aforementioned hotspot analysis of hardware resources, previous research has shown that thread mapping is a powerful tool for resource management. However, the difficulty of managing multiple hardware resources simultaneously and the variable nature of workloads hinder the efficiency of thread mapping algorithms. Despite in-depth and extensive research on this topic, correctly mapping threads to achieve optimal performance for arbitrary workloads remains an open question. Previous work has focused only on memory hierarchies or other single resources. A better approach is to consider both memory and processor resources (e.g., branch predictors, memory disambiguation units, etc.) when focusing on memory hierarchies, and to assess their relative importance to identify the key resources causing performance differences.

[0061] Optionally, based on the above problems, embodiments of this application provide a shared resource management technique as a solution. This technique determines the critical hardware resources that the thread mapping algorithm must consider and the secondary resources that do not need to be considered based on the memory and processor resources of the software under analysis during runtime, and then performs thread mapping. When mapping single-threaded applications, only shared memory resources are considered. For multi-threaded applications, thread mapping must consider more resources and thread characteristics to achieve better performance.

[0062] Step 304: Obtain the memory block usage information of the software to be analyzed during execution, and determine the memory allocation method based on the memory block usage information; the memory allocation method includes releasing memory blocks.

[0063] For example, obtaining information about memory block usage during the execution of software under analysis can be achieved using memory perspective. Memory perspective is an investigation into the memory usage of the software under test. Memory perspective technology can promptly detect memory leaks and out-of-bounds memory access issues, providing security for the software system while ensuring its normal operation. In other words, memory perspective includes memory leak detection technology.

[0064] Specifically, based on memory leak detection technology, the system obtains information about memory block usage during software execution, including: a memory block information acquisition module, which acquires information such as whether a memory block has been allocated, the allocation timestamp of allocated memory blocks, and the memory header information of allocated memory blocks. The memory header information includes the size of the allocated memory block, function call information, and the location of the called function in the file; a release judgment module, which automatically determines whether allocated memory blocks need to be released before the current timestamp based on existing real-time data and detects software memory leaks; a memory reclamation module, which reclaims the corresponding memory blocks after detecting memory leaks; a memory leak problem recording module, which records relevant information about memory leaks, including memory block information, allocation timestamp, memory block termination timestamp, and memory block reclamation timestamp; and a display module, which visually displays the memory usage over time, shows the identified memory leaks, and the reclamation of leaked memory.

[0065] For example, embodiments of this application also include a memory access out-of-bounds detection technology to detect memory access out-of-bounds issues. Memory access out-of-bounds refers to the contamination of memory after it has exceeded its limits. Common debugging methods can only locate the code using the contaminated memory, but cannot locate the code causing the memory access out-of-bounds problem. Memory access out-of-bounds can occur in the data segment memory, stack, or heap. Heap memory is the most frequently used and globally accessible, therefore heap memory out-of-bounds is the most common and the most difficult to locate. Common solutions to memory access out-of-bounds problems rely on business experience and testing to continuously narrow down the scope, or porting to other more powerful software systems and relying on powerful hardware and tools for localization. However, these solutions often encounter problems due to changes in the environment or the difficulty in reproducing the simulated business logic.

[0066] Specifically, the memory access out-of-bounds detection technology in this application detects memory access out-of-bounds issues to locate the code causing the out-of-bounds access. The specific methods include: a setting module that sets up a detection interface for detecting memory out-of-bounds access, which encapsulates standard memory allocation functions and adds boundary detection logic; a memory addition module that adds adjacent protective memory at both ends of the allocated valid memory to prevent program crashes when an out-of-bounds access occurs, thus preventing the detection interface from being called normally; a detection interface calling module that allows the program to still call the aforementioned memory out-of-bounds detection interface to perform memory out-of-bounds detection when an error occurs; an out-of-bounds memory determination module that detects whether the protective memory of each valid memory is contaminated by memory out-of-bounds access through the aforementioned memory out-of-bounds detection interface, and determines the out-of-bounds memory in all valid memory; and a code determination module that obtains the stack information corresponding to the out-of-bounds memory, obtains the function call relationship based on the stack information, and determines the creation location of the out-of-bounds memory in the code based on the call relationship.

[0067] Understandably, with the increasing scale of modern software, software developers often need to allocate and release memory during development processes, resulting in a large number of memory allocations and releases occurring in conjunction with business or control flows. Upon detecting memory leaks during software operation, it's crucial to quickly release memory and add it to free memory space for future allocation to maintain system efficiency. Otherwise, memory overflow issues can easily occur, necessitating coordinated and synchronized memory management.

[0068] Based on this, by way of example, this application proposes a concurrent memory management technology in the software running state as a solution, specifically including: establishing a memory cache, when memory is released, the memory space is not released immediately, but memory-related information is put into a cache queue, when memory allocation is requested, it is determined whether there is cache memory available in the cache queue, if so, it is allocated directly to improve allocation efficiency.

[0069] Furthermore, after detecting a memory access out-of-bounds issue, adjacent protective memory blocks need to be added at both ends of the requested valid memory. The size of these protective memory blocks affects the detection of memory out-of-bounds issues and can even impact software operation. On one hand, if the allocated protective memory is too large and the system has limited remaining memory, memory overflow is likely to occur; on the other hand, if the allocated protective memory is too small, it will reduce the performance of memory out-of-bounds detection. Therefore, the optimal size of the allocated protective memory needs to be considered using artificial intelligence technology to ensure the performance of memory out-of-bounds detection without affecting software operation.

[0070] Based on this, optionally, embodiments of this application provide an artificial intelligence-based automatic prediction technology for protected memory size as a solution, specifically including: developing artificial intelligence technology capable of predicting protected memory size, formulating an evaluation scheme for protected memory size under different remaining memory spaces, determining the optimal protected memory size under different remaining memory spaces according to the scheme and constructing a dataset, using the dataset to train an AI engine, and finally using the AI ​​engine to predict the optimal protected memory size for different remaining memory space conditions.

[0071] Step 306: Based on the system architecture configuration file, identify performance bottlenecks and perform throughput detection and analysis on each disk based on the actual load of each disk.

[0072] Throughput can refer to resource throughput, which reflects the server's load capacity and is a crucial analytical metric in performance tuning and fault detection. For CPU, disk, and network resources, many mature tools exist for testing the throughput of single-machine deployed software systems; for example, the iperf tool can easily test network throughput. Distributed system performance is closely related to CPU and disk throughput, but there is a lack of automated testing and analysis technologies. Furthermore, the complexity of deploying existing testing tools, distributing test data, and statistically analyzing test results increases with the number of distributed nodes.

[0073] For example, based on the above problems, embodiments of this application propose automatic deployment technology for testing tools and automatic detection technology for distributed system resource throughput in distributed scenarios, supporting real-time dynamic analysis of the throughput of various resources in large-scale complex distributed systems. Specifically, performance bottlenecks are identified based on system architecture configuration files, and throughput detection and analysis are performed on each disk based on the actual load of each disk.

[0074] Understandably, the current mainstream performance testing method in distributed scenarios such as server clusters uses an intermediate proxy to monitor and collect commands sent by concurrent clients, generate scripts to send to the application server, and then monitor the server's feedback. However, when installing testing tools, single-machine deployments are limited by CPU and memory, failing to meet the testing needs of highly integrated network systems. Distributed testing tools, on the other hand, install applications via plugins or scripts, binding the application's operation, configuration, and management to the current system. During application upgrades, updates, and version rollbacks, manual modification of test data and scripts is required, which is highly inconvenient. Furthermore, using distributed testing tools requires pre-starting the testing tools on each node. If additional test data is available, the data files must be manually split and placed in the same path on each remote server. Therefore, a large number of nodes increases the resource and network overhead of the testing tool client, polluting the test results. Moreover, since all nodes use the same test data, the test results do not reflect real-world scenarios.

[0075] Furthermore, the dynamic analysis tool for distributed resource throughput requires defining a master server node to establish a test tool version image repository and pre-store child node configuration information and historical test data for each node. The master node intelligently predicts the tool version for each node and deploys the test tool image through a pre-configured method. The master node adds the configuration information corresponding to each child node, such as IP address and port, to the control list. Based on the child node configuration information in the control list, the master node splits the total test data into different sub-test data and pushes them to all child nodes. As the test control unit, the master node sends corresponding commands to the child nodes according to the test tasks, and each node executes the tasks and reports the execution results.

[0076] Based on the above, it's understandable that CPU throughput in a distributed system reflects the system's transaction processing speed. Performance bottlenecks shift across nodes, making testing technically challenging. Understanding resource expansion models, verifying performance with limited resources, and navigating the lengthy performance problem localization process are pressing issues. Furthermore, distributed storage systems contain numerous disks, inevitably leading to some disks underperforming. Detecting disk throughput is a crucial performance testing method. However, disk throughput is affected by I / O load characteristics (read / write ratio, sequential and random operations, number of worker threads, queue depth, data record size), system configuration, operating system, disk drivers, and other factors. Dynamically detecting disk throughput during distributed storage system operation can produce numerous fluctuating and inaccurate test results.

[0077] For example, based on the above problems, this application provides a distributed storage CPU and disk throughput detection technology as a solution, specifically including: analyzing potential bottlenecks based on system architecture configuration files, locating resources that can be expanded during testing, and automatically modeling test scenarios. First, small-scale testing and verification are performed to identify performance bottlenecks caused by application and system configuration; then, medium-scale optimization and improvement are conducted to clarify performance bottlenecks caused by the database and its usage; finally, large-scale investigation is carried out to find performance limits caused by underlying issues such as bandwidth and operating system. Furthermore, the business logic of the distributed storage system is automatically modeled, and the actual load of each disk is determined by analyzing parameters such as disk task queue depth and the number of task threads. Disk load intensity below a threshold indicates that the disk is in a relatively idle state; throughput detection analysis is performed on this type of disk to reduce detection errors.

[0078] In some exemplary embodiments, the analysis of the software to be analyzed, including different levels of resource dumping, includes:

[0079] It receives resource dump files at different levels and obtains dump file analysis logs based on the resource dump files; the different levels include kernel level, user level and application thread level;

[0080] The dump file analysis logs were parsed to extract the basic characteristics of the crash;

[0081] Crash auxiliary features are generated based on the basic crash features, and the resource dump files are analyzed based on the basic crash features and the crash auxiliary features.

[0082] Resource dumping, or simply dumping, and the resource dump file, can be simply called a dump file. Dumping is the process of saving the contents of memory to an external file system. A dump file is a snapshot of the application at the moment of the dump. It shows the executing processes and loaded modules. If heap information is saved during the dump, the dump file will contain a memory snapshot of the application at that point in time. While existing dump analysis tools and methods support parameterization, they require manual analysis of each resource individually and are only applicable to specific resources, making them inefficient.

[0083] Specifically, this application proposes a resource dump analysis method that dumps resources at the kernel, system, and application levels of the object under test, and analyzes the resulting dump files. The method mainly includes: receiving the dump files; scheduling a debugging analysis engine to scan the dump files to obtain dump file analysis logs; parsing the dump file analysis logs to extract basic crash features; generating auxiliary crash features based on the basic crash features; and determining the dump files based on the basic crash features and the auxiliary crash features.

[0084] For example, embodiments of this application implement dumping and analysis of resources at three different levels: methods for dumping kernel-level, user-level, and application thread-level resources and analyzing dump files. A kernel-level dump includes all physical memory resources used by the system, including not only resources allocated to the operating system kernel and hardware abstraction layer, and memory resources allocated to kernel-mode drivers and other kernel-mode programs, but also unallocated memory resources and any memory resources allocated to user-mode applications. A user-level dump refers to dumping corresponding user-level resources in user mode to address faults occurring in user mode. This dump file includes the entire memory space of the process, the executable image of the program itself, the handle table, and other resources useful to the debugger when rebuilding the dump. An application thread-level dump corresponds to dump analysis at the application level. An application thread-level dump includes resource information related to the application's runtime environment and resources captured at a certain point during execution, including resources related to the operating system, application environment, threads, stack, locks, and memory.

[0085] Furthermore, a kernel-level dump is a process of dumping corresponding kernel-level resources in kernel mode to address faults occurring in kernel mode. A kernel dump includes all physical memory resources used by the system, including not only resources allocated to the operating system kernel and hardware abstraction layer, and memory resources allocated to kernel-mode drivers and other kernel-mode programs, but also unallocated memory resources and any memory resources allocated to user-mode applications. When analyzing a kernel-level resource dump, the corresponding computer name or network address must be located in the dump file, and the thread stack displaying a specific network send / receive activity must be found to obtain the network address. The obtained network information is used to identify the object of the crash dump, and then further crash characteristic analysis is performed to confirm the cause of the crash.

[0086] User-level dumps refer to dumping corresponding user-level resources in user mode to address failures occurring in user mode. This dump file includes the entire memory space of the process, the executable file image of the program itself, the handle table, and other resources useful to the debugger when rebuilding the dump. When analyzing user-level resource dump files, it's necessary to determine the process ID of the target application in the user-mode dump file to identify the current process at the time of the crash dump. The obtained process information is used to confirm the object of the crash dump, and then further crash characteristic analysis is performed to confirm the cause of the crash.

[0087] Application thread-level dumps correspond to dump analysis at the application level. They contain application-related resource information captured at a specific point in the application's runtime environment, including resources related to the operating system, application environment, threads, stacks, locks, and memory. Analyzing application thread-level resource dump files requires identifying the relevant threads and stacks where the failure occurred during application execution. The crash information on the obtained threads is used to pinpoint the crash point, followed by further crash characteristic analysis to confirm the cause of the crash.

[0088] Understandably, due to the diversity of software being analyzed—including industrial desktop applications, mobile applications, and distributed software—dump files typically involve dumping varying amounts of resource information based on the required data. Three types of dump files can be captured: kernel-level dump files, user-level dump files, and application thread-level dump files. Therefore, it's necessary to classify the received dump files to enable subsequent automated analysis.

[0089] Optionally, based on the above problems, this application proposes an artificial intelligence-based multi-type dump file recognition technology as a solution. Specifically, it includes: developing an artificial intelligence-based file recognition and classification technology; analyzing existing dump files of various types; extracting corresponding features; constructing a machine learning model; and fully utilizing the differences between different file types to achieve classification. By performing multi-dimensional separation at the detail level and storing large amounts of knowledge points, the accuracy of recognition is improved.

[0090] Furthermore, it is understandable that in dynamic analysis, dump analysis usually requires analysts to manually analyze each dump file one by one. Dump file analysis urgently needs an automated intelligent technology to reduce manual input, while ensuring the accuracy and efficiency of the analysis, improving the efficiency of dump file analysis, making the analysis process visible and controllable, and increasing the flexibility of the analysis process control.

[0091] Based on this, optionally, this application proposes an automated analysis technology for complex business scenarios as a solution, specifically including: using scripts to achieve automated analysis, employing distributed methods for batch processing, realizing batch and rapid analysis of dump files, and integrating operations. An automated dump file analysis technology solution is planned. For dump files generated by software crashes, the scheduling script can schedule the debugging analysis engine to scan via command line or other means to obtain dump file analysis logs. Then, through feature extraction scripts and feature judgment scripts, the dump file analysis logs are processed according to the feature rule base to obtain the final software crash judgment result and related useful information for the dump files, thereby assisting software developers in making modifications. Moreover, the crash judgment result and related useful information can be stored in a historical crash database, playing a accumulating role in future software crash analysis and identification and rule base improvement, further improving automated dump analysis.

[0092] In some exemplary embodiments, breakpoint-based debugging and tracing of the software to be analyzed includes:

[0093] Breakpoints are set in the software to be analyzed, causing the program of the software to be analyzed to execute in a preset step unit;

[0094] When the processor reaches the breakpoint, program execution stops and the debugger is interrupted.

[0095] In response to the program in the debugger completing debugging, the program resumes execution.

[0096] Among them, software debugging and tracing refers to the process of manually or using debugging tools to track and record the CPU's execution of the software during the software development and maintenance process. This involves recording the dynamic moments of the program for inspection and analysis, thereby finding and locating logical, syntactic, and design errors in the software, and finally correcting the errors.

[0097] For example, to implement software debugging and tracing, the first step is to reproduce the fault by repeating the steps that caused the fault on the system being debugged, so that the problem to be solved appears in the system being debugged. Next, the root cause needs to be identified, which involves using various debugging tools and methods to find the root cause of the software fault. A fault generally refers to a discrepancy between the software and its requirements or functional specifications, i.e., a software deficiency. These apparent deficiencies are caused by one or more internal factors, which may include behavioral errors in the code. Identifying the internal cause is the most critical and difficult step in the debugging and tracing process. The next step is to explore and implement solutions, designing and implementing solutions based on the identified root cause, resource availability, and urgency. Finally, the solution needs to be validated by testing its effectiveness in the target environment, i.e., regression testing. If the problem is resolved, the issue can be closed; otherwise, the solution needs to be readjusted and modified. Therefore, debugging and tracing is a repetitive process.

[0098] Understandably, real-time monitoring and control of software processes, achieved through single-step execution, setting breakpoints, and branch monitoring (i.e., monitoring and reporting branches and jumps in the program execution flow), are fundamental functions that software debugging tools should possess. However, locating the root cause of errors often involves a vast amount of space, encompassing numerous modules and a large number of instructions. Sometimes, it requires delving into the system's underlying code and data, demanding not only extensive knowledge but also an understanding of the various levels and modules of the software or system from top to bottom, as well as their collaborative mechanisms. Debugging tools are tightly coupled with the operating system, CPU, and compiler. For example, breakpoint debugging relies on the CPU's breakpoint instructions. When the CPU reaches a breakpoint, it interrupts and reports an exception to the operating system, which then distributes this event to the debugging tool. Consequently, debugging tasks on different platforms are not similar. Depending on the system environment in which the debugging program runs, there are currently corresponding debugging tools for desktop (Windows, Linux, DOS) applications, mobile applications, distributed software, and embedded software, such as WinDBG in Windows, ADB in Android, and JLINK in embedded software. In addition to supporting the three basic debugging and tracing methods, a debugger should generally also support visual code debugging functions, be able to establish and terminate debugging dialogues, control the execution of the debugged program, access and modify memory and registers, set and manage breakpoints, trace execution, observe the stack and stack backtrace, perform source code-level debugging, automatically compile and continue debugging after editing the source code, assemble and disassemble, manage module files, symbol files and other files, and generate and debug dump files.

[0099] To implement breakpoint tracing, a "trap," or breakpoint, needs to be set at a certain point in the program. When the CPU reaches this point, it stops executing the program being debugged, interrupting the debugger and allowing the debugger to analyze and debug. After the debugger finishes analysis, the program can resume execution. Furthermore, programs contain numerous functions and lines of code, and the execution and changes in data flow and control flow are sometimes difficult to discern directly, requiring execution and analysis according to pre-defined steps. Execution tracing techniques aim to make the program execute step-by-step according to pre-defined steps.

[0100] Based on this, optionally, embodiments of this application propose a breakpoint tracing and execution technique as a solution, specifically including: setting a breakpoint at the beginning of a code segment in memory space; interrupting the debugger when the CPU reaches the breakpoint; or setting a breakpoint at the beginning of memory for a variable or data to be monitored; hitting the breakpoint when the program accesses the memory address of this data. Breakpoints can also be set in I / O space at a specific I / O address; interrupting the debugger when the program accesses the specified I / O address port. When interrupted by the debugger, the system or debugger saves the state of the debugged program into a data structure, i.e., the execution context; the debugged program continues running only after the user inputs a command to resume execution. Based on this, according to the unit of steps, it can be divided into: executing one assembly instruction per step, which generally involves setting the CPU single-step execution flag, such as setting the TF bit in the CPU flag register, so that the CPU generates a debug exception after executing each instruction, interrupting the debugger; executing one statement in the source code per step, with the debugger collecting and calculating the execution results; executing one program branch per step; executing one task per step; and executing up to the parent function per step, that is, executing from the current function until returning to the function that called it.

[0101] In some exemplary embodiments, bottleneck analysis based on data flow is performed on the software to be analyzed, including:

[0102] Obtain the data flow of the software program to be analyzed;

[0103] Identify the location of bottlenecks based on system logs and data flow;

[0104] Obtain the input needed for bottleneck analysis using performance monitoring tools.

[0105] Bottleneck analysis can refer to performance bottleneck analysis. A performance bottleneck is a key factor limiting system performance. If the number of tasks to be completed at the bottleneck exceeds the maximum workload capacity, the bottleneck will cause delays in subsequent steps of the workflow. Due to the diversity of the systems being tested and the variety of possible locations and stages where bottlenecks may occur, the most important technical aspect of a qualified bottleneck analysis tool is how to accurately locate performance bottlenecks in the software.

[0106] Specifically, this application proposes a technique for accurately locating software performance bottlenecks, which includes: First, clarifying the data flow. By drawing a flow diagram, the data flow in the system can be more clearly displayed, helping testers to quickly analyze and predict the next possible bottleneck location during the bottleneck location process. Existing program data flow analysis tools can be used to explore the data flow in the program, draw data flow diagrams, and decompose the data flow to further locate the bottleneck.

[0107] Secondly, improve the monitoring of system logs. A comprehensive log helps in identifying bottlenecks. For example, if the system log prints an "out of memory" error when a method is executed, the cause of the memory overflow can be located. Bottleneck analysis tools monitor system logs to trace the path of anomalies and automatically pinpoint the location of bottlenecks.

[0108] Finally, utilize performance monitoring tools. Bottleneck analysis tools can leverage existing performance monitoring tools to obtain the necessary input for analysis. For example, for applications developed using Java in a B / S (Browser / Server) architecture, server performance can be monitored using JConsole or JProfiler, which come with the JDK. JConsole can remotely monitor the server's CPU, memory, thread status, etc., and plot the changes. Spotlight can be used to monitor database usage.

[0109] In some exemplary embodiments, bottleneck analysis includes: analysis of bottlenecks in hardware resources, analysis of bottlenecks in application software, analysis of bottlenecks in the operating system, and analysis of bottlenecks in network devices.

[0110] Specifically, in analyzing hardware resource bottlenecks, we study bottlenecks related to CPU, RAM, and other components. For example, if the CPU's sustained utilization exceeds 95%, a performance bottleneck can be considered to have occurred in the hardware. In analyzing application software bottlenecks, we study bottlenecks at the application software level, such as application servers, web servers, and database systems. For example, regarding the JDBC connection pool on the WebLogic platform, if an increase in load leads to an insufficient number of existing connections, forcing the system to dynamically add more connections, then a performance bottleneck can be considered to have occurred in the database.

[0111] In analyzing operating system bottlenecks, we study bottleneck issues in operating systems such as Windows, Linux, and Android. For example, in Windows systems, improper virtual memory settings can lead to abnormally frequent virtual memory swapping when physical memory is insufficient, resulting in a significant increase in transaction response time. This can be considered a performance bottleneck in the operating system. In analyzing network device bottlenecks, we study bottleneck issues in devices such as firewalls, dynamic load balancers, and switches. For example, a dynamic load balancer uses a dynamic load distribution mechanism. When it detects that the hardware resources of an application server have reached their limit, the dynamic load balancer sends subsequent transaction requests to other application servers with lighter loads. If the dynamic load balancing mechanism fails to function effectively, then a performance bottleneck can be considered to have occurred on the network device.

[0112] For example, this application proposes a bottleneck analysis tool for various software forms. This tool can combine the application architecture, business scenarios and implementation details of the system under test to automatically analyze and test the software's response time, processing speed, fault tolerance and other aspects, find the system's performance bottlenecks, and automatically provide developers with processing suggestions to solve the performance bottlenecks.

[0113] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0114] Based on the same inventive concept, this application also provides a software dynamic analysis apparatus for implementing the software dynamic analysis method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more software dynamic analysis apparatus embodiments provided below can be found in the limitations of the software dynamic analysis method described above, and will not be repeated here.

[0115] In one exemplary embodiment, such as Figure 4As shown, a software dynamic analysis device 900 is provided, including: an online dynamic analysis module 901 and an offline dynamic analysis module 902, wherein:

[0116] The online dynamic analysis module 901 is used to perform online dynamic analysis of the actual operating status of the software to be analyzed; the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed.

[0117] The offline dynamic analysis module 902 is used to perform offline dynamic analysis on the behavior of the software under analysis in response to the end of the software's operation. The offline dynamic analysis includes at least the analysis of resource dumps of the software under analysis at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

[0118] In one embodiment, the online dynamic analysis module 901 includes:

[0119] The thread mapping module is used to determine key hardware resources based on the memory and processor resources of the software under analysis during runtime, and to perform thread mapping; key hardware resources include at least shared memory resources.

[0120] The memory allocation module is used to obtain the memory block usage information of the software under analysis during execution and determine the memory allocation method based on the memory block usage information; the memory allocation method includes releasing memory blocks;

[0121] The throughput detection module is used to identify performance bottlenecks based on the system architecture configuration file and to perform throughput detection and analysis on each disk based on the actual load of each disk.

[0122] In one embodiment, the offline dynamic analysis module 902 includes a resource dump analysis module, which is used to receive resource dump files at different levels and obtain dump file analysis logs based on the resource dump files; the different levels include kernel level, user level and application thread level; the dump file analysis logs are parsed to extract basic crash features; crash auxiliary features are generated based on the basic crash features, and the resource dump files are analyzed based on the basic crash features and the crash auxiliary features.

[0123] In one embodiment, the offline dynamic analysis module 902 includes a debug tracing module, which sets breakpoints based on the software to be analyzed, causing the program of the software to be analyzed to execute in a preset step unit; when the processor reaches the breakpoint, it stops executing the program and interrupts it in the debugger; in response to the program in the debugger being debugged and completed, it causes the program to resume execution.

[0124] In one embodiment, the offline dynamic analysis module 902 includes a bottleneck analysis module, which is used to obtain the data flow direction of the program of the software to be analyzed; obtain the location of the bottleneck based on system logs and data flow direction; and obtain the input required for bottleneck analysis based on performance monitoring tools.

[0125] In one embodiment, bottleneck analysis includes: analysis of bottlenecks in hardware resources, analysis of bottlenecks in application software, analysis of bottlenecks in the operating system, and analysis of bottlenecks in network devices.

[0126] Each module in the aforementioned software dynamic analysis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0127] In one exemplary embodiment, such as Figure 3 As shown, a dynamic analysis tool, or software dynamic analysis system, is provided to implement the aforementioned software dynamic analysis method. Specifically, this application embodiment provides an automated and intelligent dynamic analysis toolset, namely a software dynamic analysis system, which supports comprehensive, efficient, and accurate analysis of the key properties of software in terms of spatiotemporal performance. Figure 3 A system architecture diagram of the dynamic analysis tool is provided. Regarding supported software types, the tool supports dynamic analysis of industrial desktop applications, mobile applications, and distributed software. Based on the characteristics of these software types, the tool has the ability to obtain program execution information from corresponding software runtime logs, code instrumentation, and platform interfaces, and supports monitoring the operation of CPU, memory, hard disk, and network. Based on the collected information, the tool provides efficient hotspot analysis, memory overview, resource throughput analysis, dump analysis, debug tracing, and bottleneck analysis. Specifically, the tool supports both online and offline dynamic analysis. Online dynamic analysis focuses on analyzing the actual running state of the software during its operation, with hardware resource performance analysis as its key technology. Offline dynamic analysis analyzes the recorded software execution behavior after the program has finished running, with resource dump analysis, debug tracing, and bottleneck analysis as its key technologies.

[0128] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a dynamic software analysis method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0129] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0130] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0131] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0132] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0133] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0134] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0136] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A software dynamic analysis method, characterized in that, The method includes: The actual operating status of the software to be analyzed is analyzed online dynamically; the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed. In response to the end of the operation of the software to be analyzed, an offline dynamic analysis is performed on the obtained running behavior of the software to be analyzed; the offline dynamic analysis includes at least the analysis of resource dumps of the software to be analyzed at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

2. The method according to claim 1, characterized in that, The online dynamic analysis of the actual operating status of the software to be analyzed includes: Based on the memory and processor resources of the software under analysis during runtime, key hardware resources are identified and thread mapping is performed; the key hardware resources include at least shared memory resources. The memory block usage information of the software under analysis during execution is obtained, and a memory allocation method is determined based on the memory block usage information; the memory allocation method includes releasing the memory blocks. Performance bottlenecks are identified based on system architecture configuration files, and throughput detection and analysis are performed on each disk based on the actual load of each disk.

3. The method according to claim 1, characterized in that, The analysis of the software to be analyzed, including resource dumping at different levels, includes: Receive resource dump files at different levels, and obtain dump file analysis logs based on the resource dump files; the different levels include kernel level, user level, and application thread level; The dump file analysis logs were parsed to extract the basic characteristics of the crash; Based on the basic crash characteristics, auxiliary crash characteristics are generated, and the resource dump file is analyzed based on the basic crash characteristics and the auxiliary crash characteristics.

4. The method according to claim 1, characterized in that, The step of performing breakpoint-based debugging and tracing on the software to be analyzed includes: Breakpoints are set based on the software to be analyzed, causing the program of the software to be analyzed to execute in a preset step unit; When the processor reaches the breakpoint, the program execution stops and is interrupted by the debugger; In response to the program in the debugger being debugged and completed, the program resumes execution.

5. The method according to claim 1, characterized in that, The bottleneck analysis of the software to be analyzed based on data flow includes: Obtain the data flow of the program in the software to be analyzed; The location of the bottleneck is determined based on the system logs and the data flow; The input required for the bottleneck analysis is obtained using performance monitoring tools.

6. The method according to any one of claims 1 to 5, characterized in that, The bottleneck analysis includes: analysis of hardware resource bottlenecks, analysis of application software bottlenecks, analysis of operating system bottlenecks, and analysis of network device bottlenecks.

7. A software dynamic analysis device, characterized in that, The device includes: The online dynamic analysis module is used to perform online dynamic analysis of the actual operating status of the software to be analyzed; the online dynamic analysis includes at least the performance analysis of the hardware resources of the software to be analyzed. The offline dynamic analysis module is used to perform offline dynamic analysis on the behavior of the software under analysis in response to the end of the software's operation; the offline dynamic analysis includes at least the analysis of resource dumps of the software under analysis at different levels, debugging and tracing based on breakpoints, and bottleneck analysis based on data flow.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images