Data processing method and system

Abstract

The embodiment of the invention provides a data processing method and system. In the method, in response to a calling operation of a to-be-tracked method for a target application, a method parameter corresponding to the to-be-tracked method is obtained through a preset instrumentation code, and the preset instrumentation code is a code pre-injected at a preset position of the to-be-tracked method in a section injection mode; link analysis is carried out on the method parameters corresponding to all the to-be-tracked methods, calling link data corresponding to all the to-be-tracked methods are determined, and the calling chart comprises the calling hierarchical relation of all the to-be-tracked methods; and generating a calling chart corresponding to the target application based on the calling link data corresponding to each to-be-tracked method.

Description

Technical Field

[0001] This specification relates to the field of data processing technology, and in particular to a data processing method and system. Background Technology

[0002] In current software development processes, code review (tracking) is a crucial step in ensuring application / software quality and security. However, most companies and teams in this field often rely on manual review to discover vulnerabilities and check for errors in the code. This approach is highly dependent on the experience and skill level of the reviewers, resulting in a lengthy review process. This is especially true when dealing with large-scale or complex code, where the efficiency bottleneck of manual review becomes even more apparent, severely impacting the overall software development schedule.

[0003] In related technologies, static code analysis tools or automated scanning tools are used to assist manual review in order to improve the efficiency of code tracing. These tools can identify some common vulnerabilities and code defects based on preset rules or pattern matching, but their detection scope is limited and the false positive rate is high. For complex logical vulnerabilities or application-specific issues, in-depth analysis through manual intervention is still necessary. The assistance effect of automated tools is limited and cannot fundamentally solve the problem of low tracing efficiency.

[0004] Therefore, how to improve the efficiency of code tracing, reduce the time cost of manual review, and at the same time ensure the accuracy and comprehensiveness of code tracing / mining has become an urgent technical problem to be solved.

[0005] The background information is merely information known only to the inventor and does not imply that such information had entered the public domain before the date of this application, nor does it imply that it could be considered prior art in this disclosure. Summary of the Invention

[0006] This specification provides a data processing method and system that can be applied to scenarios requiring automated and comprehensive tracking and mining of the code of a target application / software.

[0007] Firstly, this specification provides a data processing method, comprising: responding to a call operation of a method to be traced for a target application, obtaining method parameters corresponding to the method to be traced through preset instrumentation code, wherein the preset instrumentation code is code pre-injected at a predetermined position in the method to be traced via aspect injection; performing link analysis on the method parameters corresponding to each method to be traced to determine call link data corresponding to each method to be traced, wherein the call graph includes the call hierarchy relationship of each method to be traced; and generating a call graph corresponding to the target application based on the call link data corresponding to each method to be traced.

[0008] In some embodiments, before obtaining the method parameters corresponding to the method to be traced through preset instrumentation code, the method further includes: in response to a class loading event for the target application, determining a class to be traced, the class to be traced containing at least one method to be traced; and inserting the preset instrumentation code at a predetermined position in the method to be traced through the aspect injection method based on a preset instrumentation strategy.

[0009] In some embodiments, the class to be tracked includes multiple methods. Before inserting the preset instrumentation code at a predetermined position in the method to be tracked through the aspect injection method, the method further includes: filtering the multiple methods of the class to be tracked based on preset filtering rules to obtain the method to be tracked.

[0010] In some embodiments, the target application includes multiple code packages, each code package includes multiple classes, and the preset filtering rules include a preset whitelist, a preset framework list, and a preset blacklist. Filtering the multiple methods of the class to be tracked based on the preset filtering rules to obtain the method to be tracked includes: filtering the multiple packages based on the preset whitelist to determine the target package within the preset whitelist; filtering the multiple classes within the target package based on the preset framework list to obtain the class to be tracked; and filtering the multiple methods of the class to be tracked based on the preset blacklist to obtain the method to be tracked.

[0011] In some embodiments, the preset filtering rules include a starting method filtering rule, which is used to determine the starting method to be tracked for the class to be tracked. The step of filtering the plurality of methods of the class to be tracked based on the preset filtering rules to obtain the method to be tracked includes: performing starting point detection on the plurality of methods of the class to be tracked based on the starting method filtering rule to determine the corresponding starting method to be tracked.

[0012] In some embodiments, the method further includes: dynamically updating at least a portion of the preset filtering rules through a preset interface.

[0013] In some embodiments, the method parameters include: input parameters, return values, output parameters, the tracking identifier corresponding to the method to be tracked, and the parent level identifier.

[0014] In some embodiments, performing link analysis on the method parameters corresponding to each of the methods to be traced to determine the call link data corresponding to each of the methods to be traced includes: constructing a call tree based on the parent level identifier corresponding to each of the methods to be traced to determine the call hierarchy relationship between each of the methods to be traced.

[0015] In some embodiments, generating a call chart for the target application based on the call chain data corresponding to each of the methods to be traced includes: generating a call chart for the target application based on the call hierarchy and the call chain data corresponding to the methods to be traced.

[0016] In some embodiments, the call chain data further includes pass-through parameters. The step of performing link analysis on the method parameters corresponding to each of the methods to be traced to determine the call chain data corresponding to each of the methods to be traced includes: determining multiple associated methods to be traced based on the tracking identifier; and comparing the method parameters corresponding to each of the associated methods to be traced based on a preset comparison method to identify the pass-through parameters that propagate across methods.

[0017] In some embodiments, the preset comparison method includes: a preset parameter comparison method and / or a preset hash value comparison method.

[0018] In some embodiments, the call graph includes a tree diagram and / or a sequence diagram; the tree diagram is used to display the call hierarchy of each of the methods to be traced, and the sequence diagram is used to display the temporal and concurrency relationships of each of the methods to be traced.

[0019] In some embodiments, the method further includes: calculating the number of calls, average time consumption, and total time consumption for each of the methods to be traced based on the method parameters; and generating a performance analysis report corresponding to the target application based on the number of calls, average time consumption, and total time consumption for each method to be traced.

[0020] Secondly, this specification also provides a data processing system, including at least one storage medium and at least one processor, wherein the at least one storage medium stores at least one instruction set for data processing; the at least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method described in any of the first aspects above according to the instructions of the at least one instruction set.

[0021] As can be seen from the above technical solutions, the data processing method and system provided in this specification, in response to the call operation of the method to be tracked for the target application, uses preset instrumentation code to obtain the method parameters of each method to be tracked, and performs link analysis on each method parameter to determine the call link data corresponding to each method to be tracked, and finally generates a call chart containing the call hierarchy relationship of each method to be tracked. In the above method, the data processing system realizes real-time tracking and data collection of the execution process of the method to be tracked through dynamic instrumentation, avoiding the inefficiency of traditional manual review methods, and can significantly shorten the generation time of the call chart. Secondly, the data processing system performs link analysis based on actual call parameters (method parameters), which can realize comprehensive analysis of the method to be tracked, thereby effectively improving the accuracy of vulnerability location in the method to be tracked and overcoming the high false positive rate of static analysis tools. Furthermore, the data processing system provides reviewers with an intuitive display of the execution link of the target application through the generation of visual call charts, which makes it easy for reviewers to quickly identify abnormal call paths and potential security vulnerabilities based on the call charts. Furthermore, the data processing system uses aspect injection to pre-inject instrumentation at predetermined locations in the method to be traced, achieving non-intrusive tracing of the target application. This ensures comprehensive analysis without affecting the execution efficiency of the original code. Therefore, the data processing method provided in this specification is suitable for code tracing scenarios in large-scale, complex applications, and can effectively solve the problems of low efficiency and insufficient accuracy in related technologies.

[0022] The data processing methods and other functions of the system provided in this specification are partially listed in the following description. The inventive aspects of the data processing methods and systems provided in this specification can be fully understood through practice or use of the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

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

[0024] Figure 1 A schematic diagram illustrating an application scenario of a data processing system provided according to an embodiment of this specification is shown.

[0025] Figure 2 A schematic diagram of the hardware structure of a computing device provided according to some embodiments of this specification is shown;

[0026] Figure 3A schematic flowchart of a data processing method according to an embodiment of this specification is shown;

[0027] Figure 4 A schematic flowchart illustrating a method for storing parameters according to an embodiment of this specification is shown; and

[0028] Figure 5 A flowchart illustrating a data processing method provided in another embodiment of this specification is shown. Detailed Implementation

[0029] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0030] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method.

[0031] Considering the following description, these and other features of this specification, as well as the operation and function of the related components of the structure, and the economy of assembly and manufacture of the parts, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0032] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0033] In this specification, "X includes at least one of A, B, or C" means that X includes at least A, or X includes at least B, or X includes at least C. That is, X may include only one of A, B, and C, or any combination of A, B, and C, as well as other possible content / elements. The arbitrary combination of A, B, and C can be A, B, C, AB, AC, BC, or ABC.

[0034] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0035] It should be noted that the user data obtained in this manual is authorized by the user and does not involve user privacy.

[0036] For ease of description, the terms that will appear later in this manual will be explained first.

[0037] Security Aspect: Security aspect is a concept in Aspect-Oriented Programming (AOP). It refers to abstracting common security-related functions in a system (such as permission verification, encryption and decryption, log auditing, etc.) into independent "aspects" and seamlessly integrating them into the scenario logic through a lateral approach. This decouples security functions from core functions, thereby improving system security and maintainability.

[0038] Dynamic instrumentation is a runtime technique that uses custom code snippets (stub functions) to dynamically insert into the bytecode or binary code of a target program. This allows for real-time tracking and modification of the program's execution flow and state. It is commonly used in scenarios such as debugging, performance analysis, and security monitoring. It features the advantages of not requiring modification of the target program's source code and being able to be flexibly deployed at runtime.

[0039] Application Programming Interface (API): An API is a set of definitions, protocols, and tools used to enable interaction and data communication between different software systems. By exposing specific functional modules (such as functions and endpoints), it allows developers to obtain services or manipulate data by calling the interface without understanding the underlying implementation details. It is one of the core technologies for building distributed systems, achieving software reuse, and integration.

[0040] Class loading event: In the programming language's virtual machine, when a program first uses a class (such as creating an instance of the class or accessing a static member of the class), the virtual machine is triggered to load the class's bytecode file (.class) into memory and perform a series of operations including verification, preparation, resolution, and initialization. This event is automatically triggered when a class is first used in the program, ensuring the correctness and usability of the class, and is the fundamental mechanism for dynamically loading classes at runtime.

[0041] Pass-through parameters (pass-through values): refers to the process in which, when parameters are passed between different levels or components of the system, the intermediate layer components do not modify, process, or consume the parameters in any way, but simply pass them to the next level component or dependent service without modification, until the parameters reach the final processing unit. Moreover, the content, type, or behavior of such parameters can be directly controlled by external systems (such as user input, third-party systems, configuration files, etc.).

[0042] The methods provided in this manual can be applied to scenarios where the execution chain of code corresponding to target objects such as target applications, target mini-programs, or target web pages needs to be traced. Specifically, when tracing the execution chain of code corresponding to a target object is required in the above scenarios, the data processing system can respond to the call operations of the methods to be traced in the code to be traced, obtain the method parameters corresponding to each method to be traced, and determine the call chain data corresponding to each method to be traced based on the method parameters. Then, based on the call chain data corresponding to each method to be traced, the data processing system generates a call chart corresponding to the code to be traced (the code corresponding to the target object), allowing operations and maintenance personnel to view and analyze the call chain of the code to be traced based on the call chart. This facilitates operations and maintenance personnel in intuitively discovering the call chain status of the code to be traced, and thus promptly identifying potential problems in the code to be traced.

[0043] In the above process, the data processing system plays a crucial role in link tracing. It can sort out the call chain of the code to be traced during the trial run of the code to be traced in order to obtain the call chart corresponding to the code to be traced. The call chart includes the call hierarchy of each method to be traced. The operation and maintenance personnel can trace the code to be traced based on the automated data processing method, which improves the tracing efficiency while ensuring the accuracy and comprehensiveness of the tracing of the code to be traced.

[0044] In some embodiments, in order to achieve cross-platform compatibility, the target application, target applet, or target code can all be run in a virtual machine. This running mode allows the target application, target applet, or target code to run stably in a unified environment, and allows the compiled target application, target applet, or target code to run on different platforms without recompiling.

[0045] It should be noted that the above description of application scenarios is only one of the many usage scenarios provided in this specification. Those skilled in the art should understand that when the data processing methods and systems provided in this specification are applied to other usage scenarios, their implementation methods and technical effects are similar.

[0046] Figure 1 A schematic diagram of an application scenario 100 of a data processing system 130 provided according to an embodiment of this specification is shown.

[0047] like Figure 1 As shown, the data processing system 130 can respond to the call operation of the method to be traced for the target application, obtain the method parameters of each method to be traced through preset instrumentation code, and perform link analysis on the method parameters corresponding to each method to determine the call link data corresponding to each method to be traced. Subsequently, the data processing system 130 generates a call graph containing the call hierarchy relationship of each method to be traced based on the call link data corresponding to each method to be traced. In the above method, the data processing system 130 realizes the automated tracing and data collection of the execution process of each method to be traced through dynamic instrumentation, and realizes the automated generation of the call graph by organizing the collected method parameters of each method to be traced, which greatly shortens the generation time of the call graph and improves the efficiency of call link analysis.

[0048] The data processing system 130 may be a computing system with a certain computing capability. The data processing system 130 may execute the data processing methods provided in this specification. The data processing system 130 may store data or instructions for executing the data processing methods described in this specification, and may execute or be used to execute the data or instructions. The data processing system 130 may include hardware devices with data information processing functions and the necessary programs required to drive the hardware devices. The data processing system 130 may be a single computing device or a cluster system composed of multiple computing devices; this specification does not limit this.

[0049] The data processing system 130 can be a single computing device or a cluster system composed of multiple computing devices; this specification does not limit this.

[0050] It should be noted that all user data obtained in this manual has been authorized by the user and does not involve user privacy.

[0051] Figure 2 A schematic diagram of the hardware structure of a computing device 200 according to some embodiments of this specification is shown. This computing device 200 can be used as... Figure 1 The data processing system 130 is described in some embodiments. When the data processing system 130 employs a device cluster, the computing device 200 can be any one of the devices in the data processing system 130.

[0052] like Figure 2 As shown, the computing device 200 includes at least one storage medium 230 and at least one processor 220. In some embodiments, the computing device 200 may further include an internal communication bus 210. In some embodiments, the computing device 200 may further include a communication port 250. In some embodiments, the computing device 200 may further include I / O components 260.

[0053] The internal communication bus 210 can connect different system components, including storage medium 230 and processor 220. I / O component 260 supports input / output between computing device 200 and other components.

[0054] Communication port 250 is used for data communication between computing device 200 and the outside world. For example, computing device 200 can connect to a network through communication port 250.

[0055] Storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. Storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set is computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the data processing methods provided in this specification.

[0056] At least one processor 220 is communicatively connected to at least one storage medium 230 via an internal communication bus 210. The at least one processor 220 is used to execute at least one instruction set. When the system 130 is running, the at least one processor 220 reads at least one instruction set and executes the data processing methods provided in this specification according to the instructions of the at least one instruction set.

[0057] Processor 220 can execute all the steps included in the data processing method. Processor 220 can be in the form of one or more processors. Processor 220 can issue execution instructions. Processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0058] For illustrative purposes only, only one processor 220 is shown in the accompanying drawings of the computing device 200. However, it should be noted that the computing device 200 may also include multiple processors. Therefore, the operation and / or method steps disclosed herein may be executed by a single processor or by multiple processors in combination, as described herein. For example, if processor 220 of the computing device 200 in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 220 (e.g., a first processor executes step A, a second processor executes step B, or the first and second processors jointly execute steps A and B).

[0059] Figure 3 A schematic flowchart of a data processing method according to an embodiment of this specification is shown; this data processing method P300 can be executed by a data processing system 130. Figure 3 As shown, the method P300 provided in this specification may include S310-S350, wherein:

[0060] S310: In response to a call to a method to be traced for a target application, obtain the method parameters corresponding to the method to be traced through preset instrumentation code. The preset instrumentation code is code that is pre-injected at a predetermined position in the method to be traced through aspect injection.

[0061] In the above embodiments, the data processing system injects preset instrumentation code at predetermined locations in the method to be traced, so that during the operation of the target application, the data processing system can automatically capture the actual parameter data of each method call to be traced.

[0062] Specifically, the data processing system employs aspect injection to inject pre-defined instrumentation code into predetermined locations within the method to be traced. This ensures that the injection of pre-defined instrumentation code does not require modification of the original method, achieving non-intrusive tracing. Furthermore, the pre-defined instrumentation code allows for comprehensive acquisition of data generated during the execution of the method. Secondly, by pre-setting instrumentation points and injecting pre-defined instrumentation code at predetermined locations within the method, the system accurately captures key information such as parameter values ​​and call sequences during the method's invocation process, providing a reliable data foundation for subsequent analysis of the call chain data. Thirdly, by dynamically collecting method parameters during the method's invocation process, the system effectively avoids misjudgments caused by detachment from the runtime environment. Simultaneously, the automated parameter collection mechanism reduces the workload of manual tracing, improving the efficiency of tracing the target application.

[0063] In some embodiments, the data processing system, in response to a class loading event for a target application, determines the classes to be tracked, each containing at least one method to be tracked. Then, based on a preset instrumentation strategy, the data processing system inserts preset instrumentation code at predetermined locations in the methods to be tracked using aspect injection. Through the intelligent filtering mechanism of the class loading event, the data processing system can accurately locate the classes to be tracked containing the methods to be tracked, thereby improving the targeting and efficiency of instrumentation and avoiding the performance loss caused by full instrumentation. The automated instrumentation process based on the preset instrumentation strategy ensures the consistency and reliability of the preset instrumentation code injection, and the automated instrumentation process also supports flexible adjustment of the instrumentation granularity and scope according to different user tracing needs. Furthermore, the class loading mechanism ensures that each method to be tracked is prepared for detection before its first invocation, ensuring that the data processing system can completely capture the entire execution chain of each method to be tracked from its initial invocation, providing a comprehensive data foundation for subsequent analysis and performance optimization.

[0064] Specifically, the data processing system dynamically identifies the classes to be tracked during the class loading phase and automatically injects instrumentation code into each method within those classes based on a preset instrumentation strategy. This achieves the injection of preset instrumentation code into each method. The data processing system uses the class loading event as the trigger, ensuring that the instrumentation operation is naturally synchronized with the target application's lifecycle. This avoids both the resource waste caused by injecting preset instrumentation code too early and the omission of critical calls caused by injecting it too late.

[0065] In some embodiments, when the data processing system detects that a method to be tracked is marked with a preset annotation, it determines that the marked location is a predetermined position of the method to be tracked and injects preset instrumentation code at the predetermined position. That is, by recognizing the preset annotations in each method to be identified, the data processing system can automatically identify the injection position of the instrumentation code for each method to be tracked, achieving precise and controllable code instrumentation for each method to be tracked in the target application. The data processing system's method of locating instrumentation positions based on preset annotations allows developers to flexibly annotate the instrumentation positions of the methods to be tracked with simple code, maintaining the cleanliness of the target application code while achieving fine-grained tracking control, ensuring the stability and maintainability of the instrumentation.

[0066] Among them, pre-defined annotations are added by developers during the code writing process, and are generally placed at the entry point of the method to be traced. In other words, the data processing system can insert pre-defined instrumentation code at the entry point of the method to be traced in order to obtain the method parameters generated by the method from the entry point to the exit point.

[0067] In some possible embodiments, to prevent the execution of pre-instrumented code from affecting the methods to be traced in the target application, such as preventing crashes in other traced methods caused by the pre-instrumented code, the data processing system can prevent the instrumentation code from running in an independent, isolated environment (e.g., a sandbox). This avoids crashes caused by logical defects in the pre-instrumented code itself, abnormal resource consumption, or compatibility issues with the target application, which could lead to memory overflows, thread deadlocks, or infinite loops in the virtual machine hosting the target application. The aforementioned isolation mechanism, by limiting the access permissions of the pre-instrumented code within the sandbox to the core resources of the virtual machine hosting the target application, controls the execution scope and lifecycle of the pre-instrumented code, ensuring that the operational risks of the pre-instrumented code are confined within the sandbox, thereby guaranteeing the stable operation of the target application and the normal operation of the virtual machine.

[0068] In some embodiments, the class to be tracked includes multiple methods, and the data processing system can filter the multiple methods of the class to be tracked based on preset filtering rules to obtain the methods to be tracked.

[0069] The data processing system intelligently filters multiple methods within a class using preset filtering rules to quickly identify the methods that truly need to be tracked, effectively avoiding the performance overhead of full instrumentation. By combining preset filtering rules with class loading, the system ensures that the filtering of methods to be tracked can be completed during the target application's startup phase, providing a data foundation for subsequent analysis during the application's runtime.

[0070] In some embodiments, the data processing system can dynamically update at least a portion of the preset filtering rules through a preset interface. This includes adding, deleting, and / or modifying some filtering rules. Specifically, operations and maintenance personnel can dynamically adjust the preset filtering rules based on the actual operation of the target application, thereby achieving dynamic updates of the preset filtering rules and improving the flexibility and continuity of data processing system maintenance. For example, if it is found that introducing a certain type of method during the operation of the target application results in a large number of invalid calls, then the method can be added to a blacklist through the preset interface to stop tracking that method.

[0071] For example, different target applications may correspond to different filtering rules. When tracking different target applications, the data processing system can use different preset filtering rules, thereby improving the scalability of the data processing method. The aforementioned configurable preset filtering rules enable the data processing system to flexibly adapt to the tracking needs of different target application scenarios.

[0072] In some embodiments, the target application includes multiple code packages, each code package includes multiple classes, and the preset filtering rules include a preset whitelist, a preset framework list, and a preset blacklist. The data processing system filters the multiple packages based on the preset whitelist to determine the target package within the preset whitelist. The data processing system filters the multiple classes within the target package based on the preset framework list to obtain the class to be tracked, and then filters the multiple methods of the class to be tracked based on the preset blacklist to obtain the method to be tracked.

[0073] For example, in addition to the preset filtering rules mentioned above, the data processing system can also effectively filter out a large number of repetitive and meaningless method calls in the methods to be identified by automatically identifying and skipping high-frequency tools (such as getters / setters). This achieves automated pruning of the call chain, improving the efficiency of subsequent call chain analysis and simplifying the display complexity of the subsequent call chain. In other words, the above-mentioned intelligent filtering of high-frequency tools can reduce the resource overhead of the data processing system while ensuring that no key call methods are missed, improve the readability of the call chart, and provide clearer and more targeted visual parameter basis for subsequent performance optimization and architecture analysis.

[0074] In some embodiments, the preset filtering rules include starting point method filtering rules, which are used to determine the starting point method to be tracked for a class to be tracked. The data processing system can perform starting point detection on multiple methods of the class to be tracked based on the starting point method filtering rules to determine the corresponding starting point method to be tracked. The starting point method filtering rules, through predefined starting point features (such as specific method naming patterns, annotation markers, etc.), can only identify the actual entry point method of each method, ensuring that the determined starting point method to be tracked accurately reflects the actual execution entry point.

[0075] The data processing system first limits the scope of the packages to be tracked by using a pre-defined whitelist, ensuring that the tracking is focused on the target package. Second, it filters multiple classes within the target package using a pre-defined framework list to obtain the classes to be tracked. Third, based on the starting method filtering rules, the system performs start-point detection on multiple methods under the class to be tracked to determine the starting method to be tracked. This multi-layered filtering mechanism significantly reduces the number of methods to be analyzed by limiting the target package and the classes to be tracked, while ensuring that no starting method is missed through precise starting method filtering rules. This significantly improves the efficiency and accuracy of method tracking while maintaining the completeness of the analysis, providing a precise data foundation for subsequent analysis of call chain data.

[0076] S330: Perform link analysis on the method parameters corresponding to each method to be traced to determine the call link data corresponding to each method to be traced.

[0077] In some embodiments, method parameters may include: input parameters, return values, output parameters, an identifier corresponding to the method to be traced, and a parent level identifier. Call chain data includes the call hierarchy relationship between each method to be traced. The data processing system constructs a call tree based on the parent level identifier corresponding to each method to be traced, thereby determining the call hierarchy relationship between the methods to be traced.

[0078] For example, method parameters may also include multiple parameters from the following: the identifier corresponding to the method to be tracked, the node that calls the method to be tracked, the parent calling node of the method to be tracked, the fully qualified name of the method to be tracked, the metadata of the input parameters when the method to be tracked is called, the actual value of the input parameters, the hash value of the input parameters, the return value corresponding to the method to be tracked, and the hash digest corresponding to the return value, etc. It should be understood that the above embodiments are only illustrative examples, and the parameter content that may be included in the specific method parameters can be flexibly set and adjusted according to the actual needs of the user. All method parameters generated during the execution of the method to be tracked can be stored, or all methods generated during the execution of the method to be tracked can be filtered (duplicated, sorted, merged, filtered out some preset parameters, etc.) to obtain only some target method parameters for storage. The specific parameter content and parameter range included in the method parameters to be stored can be flexibly adjusted according to the user's needs and are not limited to those given in the above embodiments.

[0079] For example, the parent layer identifier is the identifier of the parent method corresponding to the method to be traced, and the identifier for each method to be traced can be determined based on the identifier of its parent method. The method parameters of each method to be traced are stored in a corresponding node, where the node identifier can be determined based on the identifier corresponding to the method to be traced; for example, the node identifier can be consistent with the representation corresponding to the method to be traced. In some embodiments, the data processing system can generate a call graph corresponding to the target application based on the call hierarchy and the call chain data corresponding to the methods to be traced.

[0080] The data processing system generates call graphs by combining call hierarchy and call chain data, enabling visualized and intelligent analysis of the call relationships of the target application. First, the system constructs a complete call tree structure by tracing parent level identifiers to accurately reflect the hierarchical call relationships between the methods being tracked. Then, the system integrates and analyzes the call hierarchy with detailed call chain data to automatically generate a visualized call graph containing multi-dimensional information. This structured and visualized analysis method not only clearly displays the complete call path from the entry method to the underlying methods but also intuitively presents the performance data and parameter flow of key call nodes, effectively improving the efficiency of developers in problem localization and architecture understanding.

[0081] Figure 4 This specification illustrates a flowchart of a method for storing parameters according to an embodiment of the present invention. Figure 4As shown, when the target application runs in a virtual machine, the data processing system filters the methods in the target application based on preset filtering rules to determine the methods to be tracked, and stores the method data of the methods to be tracked in the corresponding nodes. For example, if the identifier corresponding to the method to be tracked, A, is 1, then the identifier of the storage node corresponding to the method to be tracked, A, is determined to be node 1, and the method data of the method to be tracked, A, is stored in node 1. If the method to be tracked, A, calls the method to be tracked, B (i.e., the method to be tracked, A, is the parent layer / node of the method to be tracked, B), then the identifier corresponding to the method to be tracked, B, is determined to be 1.1, and the identifier of the storage node corresponding to the method to be tracked, B, is determined to be node 1.1, the identifier of the parent layer corresponding to the method to be tracked, B, is determined to be 1, and the method data of the method to be tracked, B, is stored in node 1.1. If method B to be traced calls method C to be traced (i.e., method B is the parent layer / node of method C), then the identifier corresponding to method C is determined to be 1.1.1, the identifier of the storage node corresponding to method C is determined to be node 1.1.1, the identifier of the parent layer corresponding to method C is 1.1, and the method data of method C is stored in node 1.1.1. It should be understood that the above embodiments are merely illustrative examples, and the specific identifiers corresponding to each method to be traced, as well as the parent layer identifiers, can be flexibly adjusted according to user needs and are not limited to those given in the above embodiments.

[0082] In some embodiments, the data processing system can generate a unique tracking identifier for the method to be tracked when it detects that the method to be tracked is marked with a preset annotation, thereby activating full-link tracing for the method to be tracked. In some embodiments, the tracking identifier corresponding to the method to be tracked can be, for example, generated based on the parent layer identifier of the method to be tracked for each method under a target application. For example, if the parent layer identifier of method 1 is 1.1, and method 1 is the second method called under the parent layer, then the identifier corresponding to the current method can be 1.1.2. Alternatively, the identifier corresponding to the method to be tracked can be generated using the format of package name + class name + method name. Alternatively, the identifier corresponding to the method to be tracked can be generated using the hash value of package name + class name + method name + parameter signature to ensure uniqueness across instances in a distributed system. It should be understood that the above embodiments are merely illustrative examples, and the specific generation methods of the identifiers corresponding to different methods to be tracked can be flexibly adjusted according to user needs and are not limited to those given in the above embodiments. The above method enables the data processing system to accurately distinguish calls to the same method in different contexts of the target application based on the tracking identifiers of each method to be tracked, significantly improving the accuracy of call chain tracing.

[0083] In some embodiments, the call chain data further includes: pass-through parameters. The data processing system determines multiple associated methods to be traced based on the tracking identifier, and compares the method parameters corresponding to each associated method to be traced based on a preset comparison method to identify the pass-through parameters propagating across methods. For example, during the recording of pass-through parameters, the entire propagation path of the pass-through method and the external controllability identifier corresponding to the pass-through parameters can be recorded. The external controllability identifier is used to record the source of the pass-through parameters, such as whether the pass-through value parameter comes from user input or from a third-party interface.

[0084] For example, the preset comparison method may include: a preset parameter comparison method and / or a preset hash value comparison method.

[0085] In some embodiments, the preset parameter comparison method may be as follows: the data processing system may determine at least one parameter object with the same parameter name based on each parameter name, compare the parameter values ​​corresponding to each parameter object under the at least one parameter object with the same parameter name, determine whether the parameter value has changed, and if the parameter value has not changed during the transmission process, then the parameter is determined to be a transparent parameter.

[0086] The preset hash value comparison method can be as follows: The data processing system can determine at least one parameter object with the same hash value based on the hash value, and compare whether the hash values ​​corresponding to each parameter object under at least one parameter object are the same. If the hash values ​​are the same, then further compare whether the shallow field values ​​under the two object parameters with the same hash value are consistent. If they are consistent, then determine that the parameter object is a pass-through parameter.

[0087] In some embodiments, the data processing system can first compare each parameter based on a preset parameter comparison method to determine that the parameter objects that match the comparison are the pass-through parameters. Then, it can compare each parameter again based on a preset hash value comparison method to determine that the parameter objects that match the comparison are the pass-through parameters. This supplementary verification method using hash value comparison solves the identification problem caused by possible packaging type conversions during the transmission of complex parameters, improving the comprehensiveness of pass-through parameter identification. Since the data processing system compares all parameter objects each time, the dual matching mechanism of parameter value comparison and hash value comparison ensures accurate determination of pass-through parameters, avoiding missed identifications. This multi-layered parameter comparison strategy ensures both rapid identification of simple value type parameters and accurate tracking of complex object parameters, significantly improving the observability of the data flow of the target application by the data processing system.

[0088] S350: Generate a call graph for the target application based on the call chain data corresponding to each method to be traced.

[0089] The call graphs can include tree diagrams and / or sequence diagrams. Tree diagrams display the call hierarchy of each method to be traced, clearly showing the call relationships between methods in a hierarchical structure. This allows operations personnel to quickly determine the overall architecture and key call chains of the target application, facilitating subsequent architecture optimization and code refactoring. Sequence diagrams display the temporal and concurrency relationships of each method call. They visually present the time sequence and concurrency of method calls, aiding in diagnosing performance bottlenecks and concurrency conflicts in the target application. By generating these two types of call graphs, the data processing system achieves complementary visualizations, satisfying both the needs of static architecture analysis and supporting the observation of dynamic runtime behavior, providing a multi-dimensional analytical perspective for the optimization of the target application.

[0090] In some embodiments, each method to be traced in the call graph corresponds to a display node. The call graph allows users to expand / collapse a node / sub-node by clicking (e.g., single click, double click, or right-click). Users can click on any node displayed in the call graph to expand the corresponding method parameters or collapse the related parameters (e.g., specific values ​​of input parameters, specific values ​​of output parameters, return values, call stack information, and performance metrics) under that node. Furthermore, the call graph's display interface may include a search box, allowing users to perform a full-link search of the target object by entering a search command. The target object can be a target node object, a target parameter object, or a target method object, etc. It should be understood that the above embodiments are merely illustrative, and the specific functional types supported by the call graph and the specific implementation methods of different functions are not limited to those given in the above embodiments and can be flexibly adjusted according to user needs.

[0091] For pass-through parameters: Users can click on any pass-through parameter on the call chart to pop up the complete propagation path details corresponding to that pass-through parameter (e.g., through a pop-up window). The propagation path details show the complete link of the pass-through parameter from generation to output, including the processing logic of each method in the propagation path for the pass-through parameter (e.g., whether to modify or verify rules).

[0092] In some embodiments, the default display method for pass-through parameters in the call graph can be highlighting, highlighting, or displaying them differently from other parameter objects. This special display method allows operations and maintenance personnel to intuitively understand the data transmission of pass-through parameters between various levels of the data processing system, facilitating logic verification and anomaly troubleshooting. In other words, by accurately identifying pass-through parameters in the method call chain of the target application, the data processing system can effectively trace the transmission path of key parameters during runtime.

[0093] In some embodiments, the data processing system can also calculate the number of calls, execution time (execution duration), average execution time, and total execution time for each method to be traced based on the method parameters. Furthermore, the data processing system generates a performance analysis report for the target application based on the number of calls, average execution time, and total execution time for each method to be traced.

[0094] For example, a data processing system can statistically analyze the call frequency of each method based on a preset time dimension (such as per minute, per hour, or per day) to generate a performance analysis report for the target application under different dimensions.

[0095] The data processing system collects and analyzes key performance indicators such as the number of calls, average execution time, and total execution time of the methods being tracked, and automatically generates performance analysis reports. This allows the data processing system to accurately pinpoint performance bottlenecks in the application and visually demonstrate the execution efficiency of each method through quantified data, providing a reliable basis for performance optimization. Secondly, the data processing system avoids discrepancies between simulated loads and actual scenarios by statistically analyzing real-world data from the target application's runtime. Furthermore, the automated report generation mechanism significantly reduces the workload of manually collecting and analyzing performance data, enabling developers to quickly identify frequently called or time-consuming methods, providing data support for the stable operation and iterative optimization of the data processing system.

[0096] In some embodiments, the data processing system can preset alarm thresholds, such as a time alarm threshold for the average execution time of the method to be tracked, and a verification threshold for the number of unverified penetration parameters of the method to be tracked. When the average execution time of the method to be tracked exceeds the time alarm threshold, or the number of unverified penetration parameters exceeds the verification threshold, an alarm is triggered through a designated alarm channel to prompt developers to verify and handle the alarm event. The designated alarm channel can be an SMS channel, an email channel, or an enterprise communication channel, etc. The specific alarm content and alarm method can be flexibly adjusted according to user needs and are not limited to those given in the above embodiments.

[0097] For example, in call charts and performance analysis reports, methods / paths / nodes that require alerts can be colored, such as highlighted or highlighted in red, to alert users to potential problems in the current call chain, thereby enhancing the information density of call charts or performance analysis reports.

[0098] Figure 5 A flowchart illustrating another embodiment of the data processing method provided in this specification is shown, such as... Figure 5 As shown, after acquiring relevant data from the target application, the data processing system filters all methods within the target application using a dual-mode filter to obtain the methods to be tracked. The dual-mode filter is used to filter class loading events and multiple methods within the target package of the target application based on preset filtering rules to obtain the methods to be tracked. For example, the preset filtering rules include a dual filtering mechanism of a preset whitelist (preset package name whitelist com.example.*) and a starting method filtering rule. Alternatively, the preset filtering rules can also include a preset framework list and a preset blacklist to further improve the accuracy of filtering. The preset filtering rules support hot updates.

[0099] Continue as Figure 5 As shown, the data processing system, based on a security aspect-oriented engine (e.g., a Java Agent) and a pre-defined instrumentation strategy, inserts pre-defined instrumentation code at predetermined locations (e.g., the entry / exit points) of the methods to be traced via aspect injection. This allows the system to obtain the method parameters corresponding to each method. Furthermore, the data processing system stores the method parameters (including but not limited to input parameters and return values) of each method based on the corresponding storage nodes, thus obtaining the call chain data for each method.

[0100] In some embodiments, the storage structure of the call chain data corresponding to each method to be traced can be: tracing identifier - method call identifier (identifying the position of the current method to be traced in the call chain) - parent level identifier - fully qualified name of the current method to be traced - metadata of the input parameters when the current method to be traced is called - identity parameter - actual parameter value - parameter hash value - sensitive parameter identifier - storage of the original value of non-sensitive parameters - metadata of the return value of the current method to be traced - task identifier code (used to identify the processing result of the task) - hash digest of the return value - timestamp - thread identifier (the thread identifier that executes the current method to be traced) - operation tag set (used to classify and quickly retrieve the current method to be traced).

[0101] The following example illustrates the storage structure of the call chain data for the currently tracing method (com.example.a.Service.process()):

[0102]

[0103] Continue as Figure 5 As shown, the data processing system uses algorithms to parse the call chain data corresponding to each method to be traced. It associates the call relationships of the methods to be traced using trace identifiers (traceId) and identifies the passed-through parameters propagating across methods based on a comparison of parameter hash values ​​and preset parameters. This identifies call paths containing passed-through parameters as risk paths. Furthermore, the data processing system processes the call chain data corresponding to each method to be traced and the risk paths corresponding to the passed-through value data to generate a visual call chart and performance analysis report for the target application. The risk paths in the visual call chart are displayed in a preset manner. Users can gain a comprehensive view of the complete call chain, risk paths, and performance of the target application through the visual call chart and performance analysis report. Each node in the visual call chart can be clicked to expand / collapse, and the target method, input parameters, or other parameters can be quickly located in the call chart through search.

[0104] In summary, the data processing method P300 and system 130 provided in this specification involve the data processing system responding to the call operations of the methods to be traced in the target application. It uses pre-defined instrumentation code to obtain the method parameters of each method to be traced, and performs link analysis on these parameters to determine the call link data corresponding to each method. Finally, it generates a call chart containing the call hierarchy of each method. In this method, the data processing system achieves real-time tracking and data collection of the execution process of the methods to be traced through dynamic instrumentation, avoiding the inefficiency of traditional manual review methods and significantly shortening the call chart generation time. Secondly, the data processing system performs link analysis based on actual call parameters (method parameters), enabling comprehensive analysis of the methods to be traced, thereby effectively improving the accuracy of vulnerability location and overcoming the high false positive rate of static analysis tools. Furthermore, the data processing system provides reviewers with an intuitive display of the target application's execution link through the generation of visual call charts, facilitating rapid identification of abnormal call paths and potential security vulnerabilities. Furthermore, the data processing system uses aspect injection to pre-inject instrumentation at predetermined locations in the method to be traced, achieving non-intrusive tracing of the target application. This ensures comprehensive analysis without affecting the execution efficiency of the original code. Therefore, the data processing method provided in this specification is suitable for code tracing scenarios in large-scale, complex applications, and can effectively solve the problems of low efficiency and insufficient accuracy in related technologies.

[0105] This specification, in another aspect, provides a computer-readable non-transitory storage medium storing at least one instruction set of executable instructions for data processing. When the at least one instruction set is executed by a processor, it instructs the processor to implement the steps of the data processing method P300 of this specification. In some possible embodiments, various aspects of this specification may also be implemented as a program product comprising program code. When the program product is run on a data processing system 130, the program code causes the system 130 to perform the steps of the method P300 described in this specification. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on the system 130. However, the program product of this specification is not limited thereto. In this specification, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination of the foregoing. Program code for performing the operations described herein may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar programming languages.

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

[0107] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure may be presented by way of example only and may not be restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0108] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0109] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as separate embodiments. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. And the content of each secondary embodiment is valid even if it contains fewer than all the features of a single foregoing disclosed embodiment.

[0110] Every patent, patent application, publication of a patent application, and other material, such as articles, books, specifications, publications, documents, and literature (excluding any related historical examination documents), cited in this disclosure is incorporated herein for all purposes, including, for example, in the specification and claims of this disclosure. However, in the event of any inconsistency or conflict between the descriptions, definitions, and / or terms used in the foregoing and those used in this disclosure, the descriptions, definitions, and / or terms used in this disclosure shall prevail.

[0111] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A data processing method, comprising: In response to a call operation to a method to be traced for a target application, the method parameters corresponding to the method to be traced are obtained through preset instrumentation code, wherein the preset instrumentation code is code pre-injected at a predetermined position in the method to be traced through aspect injection. Perform link analysis on the method parameters corresponding to each of the methods to be traced to determine the call link data corresponding to each of the methods to be traced. The call link data includes the call hierarchy relationship of each of the methods to be traced. as well as Based on the call chain data corresponding to each of the methods to be traced, a call chart corresponding to the target application is generated.

2. The method according to claim 1, wherein, Before obtaining the method parameters corresponding to the method to be traced through preset instrumentation code, the method further includes: In response to a class loading event for the target application, a class to be tracked is determined, the class containing at least one of the methods to be tracked; and Based on a preset instrumentation strategy, the preset instrumentation code is inserted at a predetermined position in the method to be traced using the aspect injection method.

3. The method according to claim 2, wherein, The class to be traced includes multiple methods. Before inserting the preset instrumentation code at a predetermined position in the method to be traced via the aspect injection method, the method further includes: The methods of the class to be tracked are filtered based on preset filtering rules to obtain the methods to be tracked.

4. The method according to claim 3, wherein, The target application includes multiple code packages, each code package includes multiple classes, and the preset filtering rules include a preset whitelist, a preset framework list, and a preset blacklist. The filtering of the multiple methods of the class to be tracked based on the preset filtering rules to obtain the methods to be tracked includes: Based on the preset whitelist, the multiple packets are filtered to determine the target packet within the preset whitelist; Based on the preset framework list, multiple classes within the target package are filtered to obtain the class to be tracked; and The methods of the class to be tracked are filtered based on a preset blacklist to obtain the methods to be tracked.

5. The method according to claim 3, wherein, The preset filtering rules include starting method filtering rules, which are used to determine the starting method to be tracked for the class to be tracked. The step of filtering the multiple methods of the class to be tracked based on the preset filtering rules to obtain the method to be tracked includes: Based on the starting point method filtering rules, the starting point detection is performed on the multiple methods of the class to be tracked to determine the corresponding starting point method to be tracked.

6. The method according to claim 5, wherein, The method further includes: At least a portion of the preset filtering rules are dynamically updated through a preset interface.

7. The method according to claim 1, wherein, The method parameters include: input parameters, return value, output parameters, tracking identifier corresponding to the method to be tracked, and parent level identifier.

8. The method of claim 7, wherein, The step of performing link analysis on the method parameters corresponding to each of the methods to be traced, and determining the call link data corresponding to each of the methods to be traced, includes: A call tree is constructed based on the parent level identifier corresponding to each of the methods to be traced, and the call hierarchy relationship between the methods to be traced is determined.

9. The method according to claim 8, wherein, The step of generating a call graph corresponding to the target application based on the call chain data corresponding to each of the methods to be traced includes: Based on the call hierarchy and the call chain data corresponding to the method to be traced, a call chart corresponding to the target application is generated.

10. The method according to claim 9, wherein, The call chain data also includes pass-through parameters. The step of performing link analysis on the method parameters corresponding to each of the methods to be traced to determine the call chain data corresponding to each of the methods to be traced includes: Based on the tracking identifier, multiple associated methods to be tracked are determined; and The method parameters corresponding to each of the associated methods to be tracked are compared based on a preset comparison method to identify the transparent parameters that propagate across methods.

11. The method according to claim 10, wherein, The preset comparison methods include: preset parameter comparison method and / or preset hash value comparison method.

12. The method according to claim 1, wherein, The call graph includes a tree diagram and / or a sequence diagram; the tree diagram is used to show the call hierarchy of each of the methods to be traced, and the sequence diagram is used to show the temporal and concurrency relationships of each of the methods to be traced.

13. The method according to claim 1, wherein, The method further includes: Based on the method parameters, calculate the number of calls, average execution time, and total execution time for each method to be traced; and Based on the number of calls, average time, and total time of each method to be tracked, a performance analysis report corresponding to the target application is generated.

14. A data processing system, comprising: At least one storage medium storing at least one instruction set for data processing; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method according to any one of claims 1-13 as instructed by the at least one instruction set.

Images