Code analysis method and device, equipment, medium and product

Abstract

The invention discloses a code analysis method and device, equipment, a medium and a product in the technical field of computers. The code analysis method comprises the steps that a function set corresponding to a first service is determined according to a code file of the first service; constructing a first function call relation graph according to the function set; identifying a first entry function and a first exit function from the first function call relation graph; first calling link information is obtained according to the first entry function, the first exit function and the first function calling relation graph, so that the first calling link information indicates a function calling link between the first entry function and the first exit function, and static code analysis processing for the first service is achieved. Therefore, other analysis (such as a code change influence range and the like) for the first service can be subsequently realized based on the first calling link information, so that the analysis effect is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a code analysis method, apparatus, device, medium, or product. Background Technology

[0002] With the development of computer technology, large and complex business systems can typically have tens of millions of lines of code and hundreds of services (such as microservices). Each service involves thousands of source files and tens or even hundreds of thousands of functions, requiring hundreds of programmers to collaborate on development and maintenance. This makes code analysis of such business systems (such as the analysis of call relationships between different functions) quite difficult, thus making how to achieve code analysis a technical problem that urgently needs to be solved. Summary of the Invention

[0003] To address the aforementioned technical problems, this application provides a code analysis method, apparatus, device, medium, and product to improve the effectiveness of code analysis.

[0004] To achieve the above objectives, the technical solution provided in this application is as follows:

[0005] This application provides a code analysis method, the method comprising: determining a set of functions corresponding to a first service based on the code file of a first service; constructing a first function call relationship graph based on the function set; identifying a first entry function and a first exit function from the first function call relationship graph; and obtaining first call chain information based on the first entry function, the first exit function, and the first function call relationship graph, wherein the first call chain information indicates the function call chain between the first entry function and the first exit function.

[0006] This application provides a code analysis apparatus, comprising: a determining unit, configured to determine a set of functions corresponding to the first service based on the code file of the first service; a constructing unit, configured to construct a first function call relationship graph based on the function set; an identifying unit, configured to identify a first entry function and a first exit function from the first function call relationship graph; and a generating unit, configured to obtain first call chain information based on the first entry function, the first exit function, and the first function call relationship graph, wherein the first call chain information indicates a function call chain between the first entry function and the first exit function.

[0007] This application provides an electronic device, the device comprising: a processor and a memory; the memory for storing instructions or computer programs; the processor for executing the instructions or computer programs in the memory, so that the electronic device performs the code analysis method provided in this application.

[0008] This application provides a computer-readable medium storing instructions or computer programs that, when executed on a device, cause the device to perform the code analysis method provided in this application.

[0009] This application provides a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for executing the code analysis method provided in this application. Attached Figure Description

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

[0011] Figure 1 A flowchart illustrating a code analysis method provided in this application embodiment;

[0012] Figure 2 A schematic diagram of a call chain provided for an embodiment of this application;

[0013] Figure 3 A schematic diagram of a code analysis process provided for an embodiment of this application;

[0014] Figure 4 A schematic diagram of the first part of the workflow of a code analysis engine provided in an embodiment of this application;

[0015] Figure 5 A schematic diagram of the second part of the workflow of a code analysis engine provided in an embodiment of this application;

[0016] Figure 6 This is a schematic diagram illustrating automatic edge patching for a scenario involving reflection-based invocation, provided as an embodiment of this application.

[0017] Figure 7 A schematic diagram of a business framework for a business system provided in an embodiment of this application;

[0018] Figure 8 This is a schematic diagram of the structure of a code analysis device provided in an embodiment of this application;

[0019] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To facilitate understanding of the technical solutions provided in this application, some technical terms are explained below.

[0021] Code analysis encompasses two main directions: static analysis and dynamic analysis. Static analysis can be further subdivided into static code analysis and binary artifact analysis. Static code analysis can be further subdivided into Abstract Syntax Tree (AST) based static code analysis and Static Single Assignment (SSA) based static code analysis. In computer science, AST refers to an abstract representation of the syntactic structure of source code. SSA is an intermediate representation (IR), characterized by each variable being assigned a value only once. In static analysis, call chains obtained based on SSA are more precise than those obtained based on AST, and SSA-based call chains can also trace parameter propagation paths. However, the analysis cost of SSA is significantly higher than that of AST. Furthermore, the essence of SSA is to convert the program source code into an SSA intermediate representation and then utilize its structured and unambiguous characteristics to perform static (without running the code) semantic analysis, data flow analysis, and control flow analysis, thereby accurately uncovering information such as program behavior, dependencies, branches, and variable usage.

[0022] A service interface refers to a service that provides external capabilities through an interface. Furthermore, for any service, if it is a Hypertext Transfer Protocol (HTTP) service, then the corresponding interface is called an HTTP interface (e.g., ...). Figure 2 The interface shown HTTP HTTP service is a service that faces the outside of the system. HTTP services can be invoked through a domain name and an Application Programming Interface (API) path. The function pointed to by the API path is the entry point function of the HTTP service (also known as the function corresponding to the HTTP interface). Furthermore, for any service, if it is a Remote Procedure Call (RPC) service, then the interface corresponding to that service is called the RPC interface (e.g., ...). Figure 2 The interface shown RPC RPC service is a remote call service that is directed to other services within the system. The RPC interface is directly associated with the entry function of the RPC service (also known as the function corresponding to the RPC interface).

[0023] Research has shown that Abstract Syntax Trees (ASTs) can perform syntactic analysis on source code to obtain a tree-like syntactic structure and the call relationships between upstream and downstream functions. Based on this, the researchers in this application attempted to use ASTs for code analysis, which specifically includes: first generating an AST by parsing the source code; then constructing a function call graph by traversing the AST, so that the function call graph can present the call relationships between different functions in the source code in a tree structure.

[0024] The research also revealed the following drawbacks of the scheme described above: ① The function call graph obtained from the AST only presents direct call relationships, lacking context (such as indirect call relationships). This means that only directly related functions can be found based on the graph, and the actual call chain presented during the runtime of a service cannot be generated. ② The AST only supports analyzing the local repository of the current service and cannot be associated with upstream services. ③ The AST does not support complex scenarios such as polymorphism, anonymous functions, and reflection calls, resulting in a broken chain in the function call graph obtained from the AST under these complex scenarios. Therefore, this scheme is more suitable for assisting in simple call analysis during local development. It has high real-time requirements but low accuracy requirements, making it unsuitable for analyzing complex scenarios such as polymorphism, anonymous functions, and reflection calls. Furthermore, because this scheme cannot provide crucial contextual information, such as call conditions, parameter passing, and exception handling, the value of the data collected based on this scheme is relatively limited. Additionally, because this scheme is more suitable for local call analysis, it is not suitable for complex scenarios such as cross-repository and cross-service operations.

[0025] The research also revealed that the researchers in this application attempted to generate call chains using a large model. Specifically, this involves: first, designing prompts for the large model based on requirements; then, the large model autonomously analyzing the call chains between different functions under the guidance of these prompts. Specifically, the large model is configured to: plan an implementation scheme based on the prompts; and use tools to perform fuzzy matching in the code repository to obtain the call chains between different functions.

[0026] Research also revealed that code analysis schemes based on large models suffer from limitations such as model illusion (fabricated facts), diverse results (repeated execution may lead to contradictory conclusions), and incomplete call chains. These limitations prevent the scheme from accurately generating the actual call chain presented during the runtime of a service. Furthermore, the code domain demands high determinism (even slight errors can introduce defects), but the uncertainty of large models is a fatal flaw. Since large models are essentially probabilistic models, this uncertainty cannot be completely eliminated. Consequently, the scheme's practical effectiveness is poor, and the generated call chains are difficult to use effectively. This results in the following characteristics: a very low lower bound in practical applications, model-generated content that can only be used as a reference, and reliance on selective manual adoption.

[0027] Based on the above research, in order to overcome at least some of the aforementioned problems (such as the inability to generate the actual call chain presented during the runtime of a certain service) and to better improve the code analysis effect, this application provides a code analysis method, which includes: firstly, determining the function set corresponding to the first service (such as any service in a business system) based on the code file of the first service, so that the function set can represent which functions are involved in the implementation code of the first service; secondly, constructing a first function call relationship graph based on the function set, so that the first function call relationship graph can describe the function call relationship presented in the implementation code of the first service; and thirdly, identifying the first entry function (such as the function corresponding to the interface used by the upstream service when calling the first service) and the first exit function (such as the function used by the first service when calling the downstream service or downstream component) from the first function call relationship graph. The first call chain information is obtained based on the first entry function, the first exit function, and the first function call relationship diagram. This information indicates the function call chain between the first entry function and the first exit function, allowing the information to describe the actual function call chain presented when the first service is running (e.g., when the first service is called by other services), as described by the implementation code of the first service. This enables the information to describe the static code analysis results of the first service in a structured manner, thus facilitating static code analysis processing of the first service. This allows for subsequent analysis of the first service (e.g., analysis of the scope of code change impact, fault location, etc.) based on the first call chain information, improving analysis efficiency and accuracy.

[0028] Furthermore, this application does not limit the executing entity of the code analysis method. For example, the method can be applied to a terminal device or a server. Alternatively, the method can be implemented through data interaction between the terminal device and the server. The terminal device can be a smartphone, computer, personal digital assistant (PDA), tablet computer, etc. The server can be a standalone server, a cluster server, or a cloud server.

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0030] To better understand the technical solution provided in this application, the code analysis method provided in this application will be explained below with reference to some accompanying drawings. For example... Figure 1 As shown, the code analysis method provided in this application includes S1-S4 below.

[0031] S1: Determine the set of functions corresponding to the first service based on the code file of the first service.

[0032] The business system refers to a system that can provide users with a variety of services; and this application does not limit the implementation method of the business system. For example, the business system may include at least one service.

[0033] The first service refers to any service in the business system; and this application does not limit the implementation method of the first service. For example, in some scenarios, the first service may at least satisfy some or all of the following constraints: the first service exists in at least one service provided by the business system (such as...). Figure 2 The current service shown); the upstream service corresponding to the first service (such as...) Figure 2 The upstream service (as shown) calls the first service via an interface; the first service calls the corresponding downstream service (such as...) in a certain way. Figure 2 The upstream service refers to a service that can directly or indirectly call the first service through an interface. An upstream service can be a service located within the business system that can call the first service via an RPC interface, or a service located outside the business system that can call the first service via an HTTP interface. Similarly, a downstream service refers to a service that can be directly or indirectly called by the first service through an interface. A downstream service can be a service located within the business system that can be called by the first service via an RPC interface, or a service located outside the business system that can be called by the first service via an HTTP interface.

[0034] It is evident that the following phenomena may occur during the operation of the business system: the upstream service calls the first service through an interface, and the first service calls the downstream service through an interface, so that the first service can perform some processing based on the data fed back by the downstream service, and the upstream service can perform some processing based on the data fed back by the first service.

[0035] The code file of the first service can describe the implementation code of the first service in a certain format (such as source code, SSA, etc.); and this application does not limit the implementation method of the code file. For example, the code file can refer to the installation package of the first service (such as...). Figure 3(The installation package shown). It can be seen that, in one possible implementation, the code analysis method provided in this application can be a static code analysis technique based on SSA.

[0036] Furthermore, this application does not limit the representation of the code file of the first service mentioned above. For example, it can be implemented using any source code language or SSA.

[0037] Furthermore, this application does not limit the method of obtaining the code file for the aforementioned first service; for example, it can use any method capable of obtaining the code file (such as...). Figure 3 The download method shown is implemented.

[0038] The function set corresponding to the first service is configured to describe some characteristics of the implementation code of the first service (such as which functions it covers), so that the function set can indicate which functions might be used when the first service runs.

[0039] Furthermore, this application does not limit the implementation of the function set corresponding to the first service. For example, the function set may include a first set (such as a local repository) and a second set (one-party, two-party, or three-party dependency libraries). The functions in the first set are the functions included in the code file of the first service, so that the first set can indicate which functions appear in the code file. The functions in the second set are the functions directly or indirectly called by the functions in the first set, so that the second set can indicate which functions recorded in the repositories the functions in the first set depend on for implementation. Thus, the function set can completely and accurately describe which functions the implementation code of the first service is executed by, and further enable the function set to indicate to a certain extent which functions may be used when the first service is running.

[0040] For the aforementioned first set, the functions in the first set are determined based on the code files of the first service, so that the first set records the functions that appear in the code files, thereby enabling the first set to represent which functions are used in the code files. Therefore, the first set can refer to a local repository configured for the first service, so that the first set records the functions written for the first service during its development, thus enabling the first set to represent which functions appear in the implementation code of the first service.

[0041] The second set mentioned above is determined based on the functions in the first set, so that the second set records functions that are directly or indirectly called by functions in the first set. This allows the second set to represent the external functions that the functions in the first set depend on. Therefore, the second set can refer to a dependency library configured for the first set, so that the second set records functions that can be directly or indirectly called (e.g., depended upon) by functions in the first set. This allows the second set to represent which external functions (e.g., functions other than those recorded in the local repository) need to be directly or indirectly called when the first service runs.

[0042] Furthermore, this application does not limit the implementation of S1 described above. For example, it can specifically be: after obtaining the code file of the first service (such as...) Figure 3 After installing the package shown, the program that builds the first service in memory according to the code file (such as...) Figure 3 The program shown is used to obtain the function set corresponding to the first service, so that the function set can indicate which functions (such as functions recorded in the local repository, functions recorded in the first, second or third-party dependency libraries corresponding to the local repository, etc.) are used to execute the implementation code of the first service, so that the function set can completely and accurately indicate which functions may be used when the first service runs.

[0043] S2: Construct the first function call relationship graph based on the function set corresponding to the first service.

[0044] Among them, the first function call relationship graph refers to the graph that describes the call relationships between different functions, based on the set of functions corresponding to the first service (such as the graph obtained from the first service). Figure 4 A tree diagram presented in a structured manner (such as one showing the call relationships indicated by the call edges in the middle) Figure 5 The tree diagram shown in the upper middle section).

[0045] In addition, the above-mentioned first function call relationship graph can at least satisfy the following constraints: different nodes in the first function call relationship graph (such as...) Figure 4 The call points shown represent different functions; the directed call edges between different nodes in the first function call graph are configured to describe function call relationships; for any node in the first function call graph, the node's attributes are determined based on the implementation code of the function represented by the node, so that the attributes can describe some characteristics of the function, such as type (e.g., ...). Figure 4 The node type shown), input parameter related information (such as...) Figure 4 The input parameter definitions shown), and output parameter related information (such as...) Figure 4 The output parameter definitions shown), and related information about variables within the function (such as those shown by...). Figure 4 The variable definition information recorded in the definition set is... Figure 4The first function call graph contains features such as variable usage information recorded in the set, constants within functions, and call chains between different code blocks presented within the function's implementation code. This allows the first function call graph to comprehensively describe the characteristics presented by the implementation code of the first service. For any side of the first function call graph (such as...) Figure 4 The properties of the edge (as shown) are determined based on the calling characteristics (such as calling direction, parameter passing during the call) between the two calling points connected by the edge.

[0046] It's important to note that a call point is a node in a call chain that represents the endpoints of a call relationship, such as the caller and callee. A call edge is a connecting edge between different call points, representing the call relationship between them. A call chain, in particular, refers to the call path from the starting function to the ending function based on the upstream and downstream call relationships (e.g.,...). Figure 2 The call chains shown are as follows.

[0047] Furthermore, this application does not limit the construction method of the first function call relationship graph. For example, it can be implemented using any method that can deduce the call relationship between different functions based on the function set, such as any static code analysis method or class hierarchy analysis (CHA).

[0048] Therefore, in one possible implementation, S2 can specifically be: performing class hierarchy analysis on the function set corresponding to the first service to obtain the first function call relationship graph (e.g., Figure 3 The CHA call graph shown enables the first function call graph to describe the call relationships between different functions presented in the function set.

[0049] It's important to note that CHA refers to a static code analysis algorithm for generating call graphs. The core objective of CHA is to analyze the inheritance or implementation hierarchy of classes or interfaces in a program to deduce the potential call targets of functions or methods, ultimately generating a call graph that includes all possible call relationships. Therefore, CHA is essentially a context-free, class-level conservative static analysis algorithm. It doesn't track the actual assignment or passing of variables; it only enumerates all possible method call targets based on the static declaration relationships between interfaces and implementation classes, as well as between parent and child classes, thus constructing a call graph covering all potential calls.

[0050] Based on the above content related to S2, after obtaining the function set corresponding to the first service, a class hierarchy analysis is performed on the function set to obtain the first function call relationship graph. This is because the function set not only records functions written for the first service (such as functions recorded in the local repository) but also records some external functions (such as functions recorded in dependent libraries), so that the first function call relationship graph constructed based on the function set (such as functions from...) is... Figure 5 The function call chain presented in the tree diagram shown in the upper half includes not only the call relationship between different functions in the local repository, but also the call relationship between functions in the local repository and functions in the dependent library, as well as the call relationship between different functions recorded in the dependent library. This breaks down the barriers between different repositories, so that the first function call relationship diagram can fully present all functions directly or indirectly called when any function in the local repository is executed, in order to better ensure the integrity of the function call chain.

[0051] S3: Identify the first entry function and the first exit function from the first function call relationship graph.

[0052] Here, the first entry function refers to the starting node of the function call chain that appears when the first service runs (e.g., when the first service is called by an upstream service), such as... Figure 2 The function shown entry , Figure 5 The entrances 1 to 2 are shown.

[0053] It should be noted that, in this application, the entry function refers to the starting function of the program or request (such as...). Figure 2 The function shown 10 or function entry Alternatively, it could be entry function 1 or entry function 2. As can be seen, an entry function can be the starting node in a function call chain, indicating that the call was initiated by an upstream service or a specific request. Furthermore, in some scenarios, the entry function can be a first-type function, such as the main function, the initialization function (init), or an unreachable entry function. Among these, the main function (e.g., ...) Figure 2 The entrance shown main ), initialization functions (such as Figure 2 The entrance shown init ) or unreachable entry function (such as Figure 2 The entrance shown 不可达There are no upstream calls to either of these functions, and the main function and initialization function are typically called only once when the current service starts. Furthermore, in some scenarios, the entry point function can be a second type of function, such as a function corresponding to an HTTP interface or an RPC interface. In this case, the function corresponding to the HTTP interface or the function corresponding to the RPC interface has upstream calls, and this function may be called repeatedly multiple times during the operation of the current service.

[0054] As can be seen, when starting a program for the first service, the first entry function can refer to the main function (such as...). Figure 2 The entrance shown main The corresponding function) or initialization function (such as Figure 2 The entrance shown init (The corresponding functions). Among them, the main function and the initialization function are called only once when the first service's program starts.

[0055] Additionally, when the first service is called by an upstream service, the first entry function can refer to the function corresponding to the interface (such as an HTTP interface or an RPC interface) used by the upstream service to call the first service, rather than the main function and initialization function, so that the function call chain 1 starting from the first entry function (such as...) Figure 2 The "function" shown entry →function 01 →function 02 →function 03 →function 04 →function exit This call chain indicates the actual function call relationship when the first service is called, rather than the function call chain 2 obtained from the analysis of the implementation code of the first service, which starts with the main function or the initialization function. As a result, function call chain 1 eliminates some functions (such as the main function or the initialization function) that do not need to be executed when the first service is called, compared to function call chain 2. This allows function call chain 1 to more accurately represent the actual function call relationship when the first service is called.

[0056] Therefore, in one possible implementation, in response to a third service calling the first service through an interface (such as an HTTP interface or an RPC interface), the aforementioned first entry function can be a function corresponding to the interface (such as...). Figure 2 The function shown entry This allows the function call chain, starting with the first entry function, to indicate the actual function call relationship when the first service is called by the third service. Here, the third service refers to the upstream service corresponding to the first service.

[0057] Furthermore, this application does not limit the identification method of the aforementioned entry function (such as the first entry function). For example, in some scenarios, corresponding identification rules can be configured for different types of entry functions so that subsequent identification processing for the corresponding entry function can be completed based on the identification rules. For ease of understanding, the following explanation is provided with examples.

[0058] As an example, for functions corresponding to RPC interfaces (such as the entry function of an RPC service), the functions corresponding to RPC interfaces exhibit the following characteristics: the RPC interface definition is stored in the service root directory; the entry function is a method that acts as a receiver pointer; the entry function has at least two input parameters, and the definitions of the first two input parameters satisfy certain specific conditions (such as being equal to context.Context and ending with Request); the entry function has at least two output parameters, and the first output parameter type ends with Request and the last output parameter type is equal to error. Therefore, in order to better identify the entry function, we can formulate entry function identification rules based on these characteristics so that we can accurately identify the entry function presented when called through the RPC interface based on the identification rules.

[0059] As can be seen, since different types of entry functions have different characteristics (such as definition and features), in order to improve the accuracy of entry function identification, we can formulate identification rules for each type of entry function based on its own characteristics. This will enable us to accurately identify various types of entry parameters based on these rules, and thus accurately identify which call points are entry functions from the large number of call points presented in the function call relationship graph.

[0060] Furthermore, in some scenarios, the recognition rules corresponding to the aforementioned entry functions can be determined based on the code navigation requirements of the actual application scenario, so that the entry functions obtained based on the recognition rules meet the requirements, thereby making the call branches generated based on the entry functions also meet the requirements, and thus making the code navigation page implemented based on the call branches meet the requirements, which is conducive to realizing personalized navigation.

[0061] Furthermore, in one possible implementation, the first entry function may also satisfy the following constraint: the first entry function is located in the local repository of the first service, so that the function call chain starting with the first entry function can indicate the data processing process initiated by the first service.

[0062] The first exit function refers to the terminal node of the function call chain that occurs when the first service is running (e.g., when the first service is called by an upstream service). Figure 2 The function shown exit , Figure 5The exits 1 to 3 shown are configured to enable the first exit function to indicate downstream objects, such as downstream services or downstream components, that are directly or indirectly called by the first service.

[0063] It should be noted that, in this application, the export function refers to a function with no downstream calls or whose downstream calls directly point to downstream services or downstream components (e.g., ...). Figure 2 The function shown exit Alternatively, it can be either exit function 1 or exit function 2. Furthermore, an exit function can be a termination node in a function call chain, a downstream service that can be called, or a downstream component. Additionally, in some scenarios, if the current service's exit function points to a downstream service (such as...) Figure 2 When the downstream service shown is an RPC service, the exit function of the current service is the same as the entry function of the downstream service. Furthermore, in some scenarios, if the exit function of the current service points to a downstream component (such as...) Figure 2 When the downstream component shown is any component, the component can be a leaf node and there are no more downstream nodes. The component can be a MySQL (My Structured Query Language) component, a Remote Dictionary Server (Redis) component, a Message Queue (MQ) component, or a Relational Database Service (RDS) component. This application does not make any specific restrictions on this.

[0064] As can be seen, when the program is started for the first service, the first exit function can refer to the terminal node in the function call chain that appears when the first service is running (such as during initialization).

[0065] Additionally, when the first service is invoked by an upstream service, the first exit function can refer to the termination node in the actual function call chain when the upstream service invokes the first service (e.g., Figure 5 The exit shown is 2), rather than the terminating node in the function call chain that appears when the first service is initialized (such as...). Figure 5 The function shown 10 This allows function call chain 1, with the first exit function as the termination node, to indicate the actual function call relationship when the first service is called, rather than function call chain 2 obtained from analyzing the implementation code of the first service. Therefore, function call chain 1, compared to function call chain 2, eliminates some functions that do not actually need to be executed when the first service is called (such as...). Figure 5 The function shown 10 This allows function call chain 1 to more accurately represent the actual function call relationship when the first service is called.

[0066] Furthermore, in one possible implementation, the first exit function can be configured to point to a second service (such as a downstream service) or component (such as a downstream component) called by the first service, so that the first exit function can represent the actual departure node when the first service is running, thereby enabling the function call chain with the first exit function as the termination node to indicate the actual function call relationship when the first service is running.

[0067] It should be noted that the implementation method of the above-mentioned exit function identification method is similar to the implementation method of the above-mentioned entry function identification method, and will not be repeated here for the sake of brevity.

[0068] Furthermore, in one possible implementation, the aforementioned first exit function can be located in the local repository of the first service, so that the function call chain terminated by the first exit function can indicate the data processing procedure implemented by the first service itself. The first exit function can be located in the dependency library corresponding to the local repository of the first service (e.g., Figure 5 In the dependent library shown, the function call chain terminating with the first exit function can indicate the data processing procedure implemented by the first service with the support of the dependent library. The first exit function can also be located in the local repository of the downstream service called by the first service, so that the function call chain terminating with the first exit function can indicate the data processing procedure implemented by the first service by calling the downstream service.

[0069] Furthermore, this application does not limit the implementation of the above-mentioned S3. For example, it can be implemented by any method that can realize the identification and processing of the entry function and the exit function based on the identification rules, such as by using a large model, a pre-built script with identification function, or an identifier.

[0070] Based on the above content related to S3, it can be seen that after obtaining the first function call relationship graph (such as...) Figure 3 Following the CHA call graph shown, the first function call graph is processed according to pre-defined rules for identifying various types of entry functions and exit functions. The identification results are then used to determine which nodes in the first function call graph belong to entry functions and which belong to exit functions. This allows for the subsequent extraction of the actual function call chain presented during the runtime of the first service from the first function call graph based on the identification results. Figure 5 The lower half shows the various call branches.

[0071] S4: Based on the first entry function, the first exit function, and the first function call relationship diagram, obtain the first call chain information, which indicates the function call chain between the first entry function and the first exit function.

[0072] The first call chain information refers to the actual function call chain presented when the first service is running (such as when it is called by an upstream service).

[0073] It should be noted that in this application, a call branch is a special type of call chain. A call branch can refer to a call chain from the entry function to the exit function. The entry function in a call branch can be a function corresponding to an HTTP interface (also known as the entry point of an HTTP service) or a function corresponding to an RPC interface (also known as the entry point of an RPC service). Furthermore, for the same set of entry and exit functions, there may be multiple call branches. Additionally, the entry function in a call branch (such as...) Figure 2 The function shown entry The function is located in the local repository of the current service, but calls the exit function in the branch (such as...). Figure 2 The function shown exit The branch may be located in the local repository or in a dependency library that is called directly or indirectly by the local repository, which increases the difficulty of building the calling branch.

[0074] In addition, the aforementioned first call chain information can at least satisfy the following constraints: the starting node in the first call chain information represents the first entry function, and the ending node in the first call chain information represents the first exit function, so that the first call chain information can indicate the function call chain between the first entry function and the first exit function, thereby enabling the first call chain information to represent the function call chain actually presented when the first service runs, and further enabling the first call chain information to represent which functions are actually used when the first service runs.

[0075] As can be seen, this application uses the first entry function and the first exit function to restrict the two endpoints of the call branch extracted from the first function call relationship graph, so that the call branch records the functions actually used when the first service runs, but does not record other functions, thereby overcoming the interference caused by other functions in the implementation code of the first service.

[0076] Furthermore, this application does not limit the implementation method of the aforementioned first call chain information. For example, in one possible implementation, when the function set corresponding to the first service includes a first set (such as...), Figure 5 The local repository shown) and the second set (such as Figure 5When the dependent library is shown, the first call chain information can at least satisfy the following constraints: the first entry function in the first call chain information is located in the first set; in response to the first exit function in the first call chain information being located in the first set, the first call chain information indicates the function call chain inside the first set, so that the first call chain information can indicate the function call chain presented by the first service, so that subsequent code navigation within the local repository of the first service can be implemented based on the first call chain information.

[0077] It should be noted that, in this application, code navigation refers to tracing all call nodes, call relationships, and call paths between the entry function and the exit function based on call branches. Furthermore, code navigation allows for the analysis of the entire call chain from partial to overall, serving as a foundation for studying intra-service interface logic and inter-service dependencies. Additionally, when the exit function is located within the local repository, it is considered intra-repository code navigation, which is relatively simple; when the exit function is partially located within a dependent library, it is considered cross-repository code navigation; and when it is necessary to study code navigation between upstream and downstream services, it is considered cross-service code navigation (e.g., associating the exit function with the corresponding entry function of the downstream service).

[0078] For example, in one possible implementation, when the function set corresponding to the first service includes a first set (such as...) Figure 5 The local repository shown) and the second set (such as Figure 5 When the dependent library is shown, the first call chain information can at least satisfy the following constraints: the first entry function in the first call chain information is located in the first set; in response to the first exit function in the first call chain information being located in the second set, the first call chain information indicates the function call chain between the first set and the second set, so that subsequent cross-repository code navigation from the local repository of the first service to its dependent library can be quickly realized based on the first call chain information, so as to overcome the interference caused by other functions recorded in the dependent library and improve efficiency.

[0079] Furthermore, this application does not limit the implementation of the above-mentioned S4. For example, it can be implemented using any method that can extract call branches from the function call relationship graph based on the entry function and the exit function, such as any tree graph decomposition algorithm (e.g., breadth-first traversal algorithm).

[0080] Therefore, in one possible implementation, S4 can specifically be: using a graph breadth-first traversal algorithm to decompose the first function call graph based on the recognition results to obtain the first call chain information, so as to achieve parallel searching of all call branches pointing to the exit function from each entry function. For ease of understanding, the following will combine... Figure 5 The function call relationship diagram shown is used for illustration.

[0081] As an example, for those by Figure 5 Taking the entry node 1 in the function call relationship graph shown in the upper half as an example, the traversal process based on the node can include the following steps:

[0082] First, push the node identified as the entry function in the function call graph, node 1, onto the stack.

[0083] Next, find all child nodes Function 1 and Function 2 of the entry point node in the function call relationship graph and push them onto the stack. Pop the entry point node from the stack and update the call chain so that the updated call chain includes the call chain "entry point 1 → function 1" and the call chain "entry point 1 → function 2".

[0084] Find all child nodes of function 5 of function 1 in the function call graph and push them onto the stack. Pop function 1 from the stack and update the call chain so that the updated call chain includes the call chain "entry 1 → function 1 → function 5" and the call chain "entry 1 → function 2".

[0085] Find all child nodes of the function 2 node, exit 3, in the function call graph. Since exit 3 is identified as the exit function, it is determined that exit 3 does not need to be pushed onto the stack. Pop the function 2 node from the stack and update the call chain so that the updated call chain includes the call chain "entry 1 → function 1 → function 5" and the call chain "entry 1 → function 2 → exit 3".

[0086] Next, find all child nodes of function 5 (function 7) and exit 2 in the function call graph. Push function 7 onto the stack. Since exit 2 is identified as the exit function, it is determined that exit 2 does not need to be pushed onto the stack. Pop function 5 from the stack and update the call chain so that the updated call chain includes the call chain "entry 1 → function 1 → function 5 → function 7", the call chain "entry 1 → function 1 → function 5 → exit 2", and the call chain "entry 1 → function 2 → exit 3".

[0087] Next, find all child nodes of the function 7 node, exit 1, in the function call relationship graph. Since the exit 1 node is identified as the exit function, it is determined that the exit 1 node does not need to be pushed onto the stack. Pop the function 7 node from the stack and update the call chain so that the updated call chain includes the call chain "entry 1 → function 1 → function 5 → function 7 → exit 1", the call chain "entry 1 → function 1 → function 5 → exit 2", and the call chain "entry 1 → function 2 → exit 3".

[0088] If an empty stack is detected, it can be determined that the traversal process for the entry node 1 has ended, and three call branches with the entry node 1 as the entry function can be obtained, such as the call branch "entry 1 → function 1 → function 5 → function 7 → exit 1", the call branch "entry 1 → function 1 → function 5 → exit 2", and the call branch "entry 1 → function 2 → exit 3".

[0089] Based on the above S1 to S4, the code analysis method provided in this application includes: firstly, determining the function set corresponding to the first service based on the code file of the first service; then constructing a first function call relationship graph based on the function set; secondly, identifying the first entry function and the first exit function from the first function call relationship graph; and then generating first call chain information based on the first entry function, the first exit function, and the first function call relationship graph, so that the first call chain information indicates the function call chain between the first entry function and the first exit function, so as to realize static code analysis processing for the first service, thereby improving analysis efficiency and analysis accuracy.

[0090]

[0091] Table 1 Examples of Reflection Invocation

[0092] Research has revealed that in certain scenarios (such as reflection calls and anonymous functions), static code analysis, due to its inherent limitations, cannot directly identify the actual calls between functions that are not upstream or downstream, leading to broken chains. For example, some functions (such as those in Table 1 above, or...) Figure 6 The calling method of the reflected function "checkout" shown is quite special, making it impossible to directly identify the call relationships for these functions from the code file of the first service using the CHA algorithm (such as...). Figure 6 The actual calls shown may result in broken chains in the CHA function call graph generated based on the code file, which in turn may lead to incomplete call branches generated based on the CHA function call graph.

[0093] Based on the above research, in order to overcome the shortcomings shown in the previous paragraph, the above code analysis method may include at least the following steps: in response to detecting the first function in the first function call relationship graph (such as... Figure 6 The HandleApi function shown satisfies the occurrence conditions corresponding to the preset chain break type. The first function call graph is processed according to the edge-padding logic corresponding to the preset chain break type, so that the processed first function call graph (also called the "second function call graph") has fewer edges added to the first function compared to the unprocessed first function call graph (e.g., ...). Figure 6The edge supplement 1 or edge supplement 2 shown is determined by the edge supplement logic, which makes the function call chain presented by the processed first function call relationship graph overcome the chain break phenomenon indicated by the preset chain break type compared to the function call chain presented by the unprocessed first function call relationship graph. This makes the function call chain presented by the processed first function call relationship graph more accurate than the function call chain presented by the unprocessed first function call relationship graph, so that the first call chain information can be generated based on the processed first function call relationship graph, the first entry function, and the first exit function. This can overcome the defects caused by the chain break phenomenon in some scenarios (such as reflection, anonymous functions, etc.) and improve the accuracy of the call branch.

[0094] For the aforementioned preset chain break types, a preset chain break type refers to a call type that may lead to chain breakage, obtained in advance through analysis of a large amount of code-related data. This ensures that the actual call indicated by the type differs from the actual call between upstream and downstream functions that can be directly identified. Furthermore, this application does not limit the implementation method of the preset chain break type. For example, the preset chain break type may include reflection calls, anonymous function calls, and package variables carrying downstream functions. Additionally, the occurrence condition corresponding to the preset chain break type refers to the condition required to identify whether the chain break indicated by the preset chain break type has occurred, so that the occurrence condition can indicate what characteristics the code file exhibits when the chain break occurs. Moreover, the edge-padding logic corresponding to the preset chain break type is formulated based on the characteristics of the preset chain break type itself. For ease of understanding, the edge-padding process corresponding to the "reflection call" type will be used as an example for explanation below.

[0095] As an example, the edge-padding process corresponding to the above "reflection call" type may include steps 11-12 below.

[0096] Step 11: Check whether there is a function in the obtained function call graph (such as the first function call graph) that meets the occurrence conditions corresponding to the "reflection call" type. If there is no function, it can be determined that no chain break caused by emission call has occurred. If there is a function, it can be determined that a chain break caused by emission call has occurred.

[0097] It should be noted that this application does not limit the implementation of the occurrence conditions corresponding to the above-mentioned "reflection call" type. For example, in some scenarios (such as scenarios where reflection calls are implemented using standard libraries), regardless of how different businesses encapsulate the reflected function, the final implementation of reflection calls cannot be separated from some methods in the standard library for recording reflection calls (such as the reflect#MethodByName method, reflect#Call method, etc.). Therefore, after obtaining the function call relationship graph (such as the first function call relationship graph), the call points can be traversed in the function call relationship graph to identify whether the function indicated by the call point involves the usage instructions of these methods, so as to determine whether a reflection call exists. It can be seen that, in one possible implementation, the occurrence conditions corresponding to the "reflection call" type can be: the function indicated by the call point (such as...) Figure 6 The HandleApi function shown contains instructions for using methods of the "reflection call" type, such as the instruction "ret, err := call(svc,"Checkout", args)" shown in Table 1 above.

[0098] Step 12: If a function satisfying the occurrence condition corresponding to the "reflection call" type is detected in the obtained function call graph (such as the first function call graph), then execute the edge-padding logic corresponding to the "reflection call" type to identify the reflected function (such as...) from the code block corresponding to the function. Figure 6 The `checkout` function shown) and reflection call functions (such as...) Figure 6 The HandleApi function shown above updates the function call graph based on the reflected function and the function that calls the reflection function, so that the updated function call graph records call edges that indicate the reflected calls between the reflected function and the function that calls the reflection function. Figure 6 (As shown in edge 1 or edge 2).

[0099] It should be noted that this application does not limit the implementation of the edge-padding logic corresponding to the above-mentioned "reflection call" type. For example, it may include: when a function with a "reflection call" is detected in the current function call relationship graph (such as... Figure 6 After the HandleApi function shown, based on information recorded in the standard library regarding reflection calls (such as the parameter methodName in the reflect#MethodByName method), the function name of the function called by reflection is analyzed from the code block corresponding to the function. Then, based on the parameter passing chain, the actual call corresponding to the function name Checkout is deduced (e.g., ...). Figure 6The actual call is shown, and the Checkout function, which is actually called by reflection, is found as the callee. Based on the location where the Checkout function is called by reflection, the call point that triggers the reflection call is the HandleApi function as the caller. Then, after traversing the function call relationship graph to find the caller and the callee, call edges that can represent logical calls or actual calls are drawn between them to complete the automatic edge filling process for reflection calls. This can overcome the broken chain phenomenon caused by reflection calls and make the final generated call branches more accurate.

[0100] Based on the relevant content of steps 11 to 12 above, for any preset chain break type, when a function that satisfies the occurrence condition corresponding to the preset chain break type is detected in the current function call relationship graph, it can be determined that a chain break phenomenon indicated by the preset chain break type has occurred. Therefore, the actual call (or logical call) presented by the code block under the preset chain break type can be analyzed from the code block corresponding to the function first; then, based on the characteristics corresponding to the preset chain break type, the caller and callee can be analyzed from the actual call (or logical call); then, based on the caller and callee, a call edge is added to the function call relationship graph. This can overcome the chain break phenomenon caused by the chain break phenomenon, so that the final generated call branch is more accurate.

[0101] Research has revealed that because the CHA algorithm conservatively calculates the relationship between the interface and the specific implementation, rather than inferring the actual implementation based on the type, the call chain generated by the CHA algorithm may contain some false alarms (such as incorrect function call relationships). This results in some false alarms in the function call relationship graph generated by CHA (such as the first function call relationship graph mentioned above).

[0102] Based on the above research, in order to overcome the shortcomings shown in the previous paragraph, the above code analysis method can include at least the following steps: performing class hierarchy analysis on the function set corresponding to the first service to obtain the first function call relationship graph (e.g., Figure 3 The CHA call graph shown); select at least one function from this set of functions (such as...). Figure 3 The VTA function shown); based on at least one of these functions, Variable Type Analysis (VTA) is performed on the first function call graph to improve the quality of the processed first function call graph (also known as the "third function call graph") compared to the unprocessed first function call graph, thus overcoming some false alarms and improving the quality of the processed first function call graph (such as...). Figure 3The VTA call graph shown is more accurate than the first function call graph before processing. This is because if the first function in the processed first function call graph meets the occurrence condition corresponding to the preset chain break type, the processed first function call graph is processed according to the edge-padding logic corresponding to the preset chain break type, so that the final function call graph (such as...) is more accurate. Figure 3 The navigation map shown presents a more accurate function call chain, thus improving accuracy.

[0103] In the context of VTA, it refers to an algorithm for generating call chains through static code analysis. The key feature of VTA is its construction of a global type propagation graph and the propagation of types within that graph, allowing it to infer the set of types a variable can take at runtime. Furthermore, the core objective of VTA is to accurately deduce the true target of functions or methods by tracing the actual type assignment and propagation chain of variables in the program, generating a function call graph that more closely reflects the actual runtime execution logic, thus compensating for the insufficient precision of the CHA algorithm. In essence, VTA is a context-sensitive, variable-level, and precise static analysis algorithm. It overcomes the limitation of CHA, which only considers the static hierarchy of classes or interfaces. VTA focuses on the actual type flow of variables, enabling it to trace the entire lifecycle of each variable from declaration and assignment to usage, at least clarifying "which struct instance a certain interface variable actually points to in a specific context," thereby accurately determining the true target of method calls. Additionally, call chains generated by VTA do not produce false positives in scenarios such as polymorphism, offering higher accuracy compared to call chains generated by CHA. Furthermore, the VTA algorithm may encounter problems such as broken links in complex scenarios such as anonymous functions and reflection calls. Therefore, this application uses the corresponding automatic edge-filling methods in these complex scenarios to overcome the broken link problem.

[0104] For at least one of the above functions (such as) Figure 3 For the VTA function shown, at least one function refers to a function selected from the function set corresponding to the first service that is required when constructing a function call relationship graph based on the VTA; and this application does not limit the implementation of at least one function, for example, it can be obtained by screening according to the rules preset by relevant personnel.

[0105] Research revealed that the current service's local repository contains a large number of functions that will not participate in the invocation process, which could affect the VTA. Additionally, because only a small subset of functions in the corresponding dependency libraries are invoked by the local repository, a large number of invalid functions exist in these dependency libraries, which could also affect the VTA.

[0106] Based on the above research, in order to better improve the analysis results, when the function set corresponding to the first service includes a first set (such as a local repository) and a second set (such as a dependency library), the process of determining at least one function may include: a second function determined from the first set, which does not meet the preset exclusion conditions; a third function determined from the second set (such as... Figure 3 The second function call graph contains a third function. Based on the second and third functions, at least one function is determined so that it can include both the second and third functions. This ensures that at least one function accurately represents the functions needed when constructing the function call graph based on VTA, avoiding interference from other functions (such as functions recorded in the local repository that will not participate in the call process, or a large number of invalid functions recorded in the dependency library), thereby improving the construction effect of the function call graph. The preset exclusion condition is configured to remove functions from the local repository that are unlikely to participate in the function call process.

[0107] As can be seen, in one possible implementation, after obtaining the local repository and its dependent libraries of the first service, some functions that will definitely not participate in the function call process are first removed from the local repository, and functions that appear in the CHA call graph (such as...) are selected from the dependent libraries. Figure 3 The valid functions shown are used to remove irrelevant functions. Then, based on the remaining functions in the local repository, the functions selected from the dependency library, and the CHA call graph, variable type analysis is performed to obtain the VTA call graph. This eliminates false alarms in the VTA call graph compared to the CHA call graph, so that a navigation graph (such as the second function call relationship graph mentioned above) can be obtained by automatically patching edges in some broken chain scenarios of the VTA call graph. This allows the navigation graph to more accurately describe the actual function call chain presented during the runtime of the current service (such as the first service).

[0108] In addition, to better improve the generation effect of call branches, the above code analysis method may include at least the following steps: adding a marker corresponding to the first entry function and a marker corresponding to the first exit function to the second function call relationship graph; determining the first call chain information from the second function call relationship graph so that the first call chain information at least presents the marker, thereby enabling the first call chain information to more accurately represent the function call chain actually presented during the runtime of the first service.

[0109] Research has revealed that, for the function call graph corresponding to the current service, there may be multiple call chains that share the same set of entry and exit functions. However, different chains within these multiple call chains correspond to different downstream objects (such as downstream services or downstream components), so that different chains within these multiple call chains can be used as different call branches.

[0110] Based on the above research, in order to better distinguish different call branches, the above code analysis method can include at least the following steps: Based on the first function call relationship graph, determine the parameter information corresponding to the first call chain information. The parameter information includes an object identifier (such as a unique identifier of a downstream service). The object identifier indicates the downstream object (such as a downstream service or downstream component) pointed to by the first exit function in the first call chain information. The parameter information and the first call chain information are stored in correspondence. In this way, the call branch can be bound to its corresponding downstream object to better distinguish different call branches, prevent false alarms, and improve the accuracy of code navigation.

[0111] For the parameter information corresponding to the aforementioned first call chain information, the parameter information is configured to uniquely identify the first call chain information; moreover, this application does not limit the method of obtaining the parameter information. For example, the parameter information can be obtained by tracking parameter-level fields, so that the parameter information at least includes some constants propagated in the function call chain presented by the first call chain information (such as the unique identifier of the downstream service, the unique identifier of the current service, the unique identifier of the upstream service, etc.). This not only enables the first call chain information with bound parameter information to be better distinguished from other call branches, but also enables the identification of the importance of the first call chain information in a certain business analysis task (such as the task of determining the impact of code changes) based on the parameter information.

[0112] Research has shown that business systems can accomplish a task by sequentially calling multiple services, thus making the task execution process encompass the function call chain presented in multiple services.

[0113] Based on the above research, in order to better meet the requirements shown in the previous paragraph, the above code analysis method may further include the following steps: In response to the fact that the first exit function in the first call chain information is the same as the second entry function in the second call chain information, a third call chain information is determined based on the first call chain information and the second call chain information. The second call chain information is generated based on the function set corresponding to the second service (such as a downstream service). The third entry function in the third call chain information is the first entry function in the first call chain information, and the third exit function in the third call chain information is the second exit function in the second call chain information, so that the third call chain information can indicate the function call chain between the first service and the second service, so that the third call chain information... It records not only the actual function call chain presented when the first service runs, but also the actual function call chain presented when the second service (such as a downstream service of the first service) runs. This allows the third call chain information to present not only the function call relationships presented by each service itself, but also the call relationships presented between different services. As a result, the third call chain information can more completely and accurately describe the actual function call chain presented when a business system integrating multiple services performs a certain task. This enables cross-service code navigation between different services to be realized based on the third call chain information, breaking down the barriers between different services and overcoming the defects that exist when cross-service code navigation cannot be realized (such as low navigation efficiency, incomplete call chain, etc.).

[0114] For the aforementioned second service, the second service refers to a downstream service called by the aforementioned first service. Furthermore, this application does not limit the method of determining the second service. For example, it can specifically be as follows: after generating first call chain information based on the function set corresponding to the first service and the parameter information corresponding to the first call chain information, the second service is determined based on the object identifier in the parameter information, and the second call chain information is determined based on the first exit function corresponding to the termination node in the first call chain information, so that the second call chain information at least satisfies the following constraints: the second call chain information is generated based on the function set corresponding to the second service; the second entry function corresponding to the starting node in the second call chain information and the first exit function corresponding to the termination node in the first call chain information are the same function. The function set corresponding to the second service is generated based on the code file of the second service; and the implementation method of the function set corresponding to the second service is similar to the implementation method of the function set corresponding to the first service described above, and will not be repeated for the sake of brevity.

[0115] In addition, in some scenarios, the above code analysis method may also include the following steps: after obtaining the first call chain information, constructing a code navigation graph corresponding to the first service based on the first call chain information (such as by...). Figure 5The lower half of the diagram shows a navigation graph that includes multiple call branches, so that the code navigation graph includes first call chain information, so that subsequent call branch queries can be performed from the code navigation graph based on the first entry function and the first exit function.

[0116] In addition, in some scenarios, the above code analysis method may also include the following steps: in response to the fact that the first exit function in the first call chain information generated based on the function set corresponding to the first service is the same as the second entry function in the second call chain information generated based on the function set corresponding to the second service (such as the downstream service), the code navigation graph corresponding to the first service and the code navigation graph corresponding to the second service are concatenated, so that the concatenated code navigation graph includes the third call chain information obtained by concatenating the first call chain information and the second call chain information, so that cross-service code navigation can be quickly realized based on the concatenated code navigation graph.

[0117] Furthermore, this application does not limit the subject executing the above-mentioned code analysis method; for example, it can employ... Figures 3 to 5 The code analysis engine shown is implemented. Specifically, the code analysis engine is configured to perform static code analysis on the business system's code files (such as SSA) to obtain call branches.

[0118] Furthermore, this application does not limit the implementation method of the above-mentioned code analysis engine. For example, in some scenarios, the code analysis engine (such as...) Figure 3The working principle of the code analysis engine (shown) can include the following process: After completing the relevant verification processing of the code file (such as the installation package) for the current service, the code file is downloaded first; then, the implementation program of the current service is created in memory based on the code file; then, a CHA function call relationship graph is generated based on the local repository and its dependent libraries recorded in memory. The call relationship presented in the CHA function call relationship graph may have problems such as false calls and a large number of false alarms; then, according to the identification rules corresponding to each entry function and each exit function, the entry function and exit function identification processing of the CHA function call relationship graph is performed to obtain the identification results; then, based on the CHA function call relationship graph, some valid functions are selected from the dependent libraries so that these valid functions can represent the functions that exist in the dependent libraries and appear in the CHA function call relationship graph; then, based on these valid functions and some functions that meet the preset exclusion conditions are deleted from the local repository, the remaining functions are... The process involves several steps: First, the VTA function is identified, ensuring it includes both valid and remaining functions. Then, a VTA function call graph is generated based on the VTA and CHA function call graphs. This VTA graph aims to eliminate false alarms compared to the CHA graph, resulting in more accurate representations of node and edge relationships. Next, some nodes in the VTA graph (e.g., nodes generated by the VTA algorithm that don't actually exist, or problematic nodes recorded in the CHA graph) are pruned to remove unnecessary function nodes, resulting in a pruned function call graph. Then, broken links appearing in the pruned graph (e.g., due to reflection, anonymous functions, or package variables) are patched to obtain a patched function call graph. Finally, the entry and exit functions indicated by the identification results are marked (e.g., ...). Figure 5 The marked function call graph is then plotted onto the edge-filled function call graph to obtain the marked function call graph. Next, a breadth-first traversal is performed on the marked function call graph to parallelly identify all call branches pointing to the exit function from each entry function in the marked function call graph and bind corresponding parameter information to each call branch. Finally, a code navigation graph is constructed based on these call branches and their bound parameter information, and the code navigation graph is stored as a compressed file. This enables static code analysis of the current service. It is evident that the code analysis engine, combining the construction characteristics of three different function call graphs, solves the problem of call branch construction for exit functions in dependency library scenarios by identifying exit functions in dependency libraries and call nodes of upstream services (such as the entry function of the current service), accurately pruning branches, and removing unnecessary function nodes.

[0119] For example, the code analysis engine provided in this application may include an engine layer, a tool layer, an application layer, and a business layer. The engine layer is configured to record the tools (such as a control flow analysis engine and a data flow analysis engine) required for static code analysis. The tool layer is configured to define how to utilize these tools to perform static code analysis. The application layer is configured to define how to use the call branches obtained through static code analysis to analyze issues (such as the impact of code changes). The business layer is configured to define how to use the analysis results provided by the application layer for related processing (such as optimization and visualization).

[0120] As can be seen, in one possible implementation, the working principle of the aforementioned code analysis engine may include: a control flow analysis engine deployed within the code analysis engine analyzes the function set (such as the local repository and its dependent libraries) corresponding to the current service to obtain the call branches presented between functions; and a data flow analysis engine deployed within the code analysis engine performs parameter passing analysis on the implementation code corresponding to the current service to obtain parameter links, so as to subsequently update the call branches using the parameter links, use the updated call branches to complete some analysis tasks (such as code change impact analysis tasks, etc.), and use the execution results of these analysis tasks to support the services provided by some businesses (such as instant messaging services, short video recommendation services, intelligent question answering services, etc.). Specifically, the control flow analysis engine is configured to at least perform tasks such as identifying entry functions and exit functions from call points, patching call edges, and constructing pruning strategies for function call relationship graphs to obtain call points, call edges, and function-level call branches. The data flow analysis engine is configured to at least execute the propagation chain of identification parameters and bind constants (such as unique identifiers for downstream services) to function-level call branches. This allows for better differentiation of call branches with the same entry and exit functions but different downstream services or components, improving accuracy in real-world scenarios. Additionally, the code analysis engine is configured to combine function-level and parameter-level call branches, enabling precise matching of call branches with downstream services and function-level code navigation. This supports various platform directions within the application layer in providing corresponding services to upper-layer businesses. Furthermore, the application layer within the code analysis engine is configured to incorporate a large model. This involves first breaking down the problem into local segments through call branches, then using the large model to solve the local problems and summarize the results to obtain a global outcome.

[0121] Research has shown that after obtaining a large number of call branches through static code analysis, requests triggered by business systems can be processed based on these call branches, such as requests to determine the impact of code changes and requests to locate faults.

[0122] Based on the above research, in one possible implementation, the code analysis method described above may include at least the following steps: In response to receiving a request triggered by a business system (such as a request to determine the impact of code changes, a request to locate faults, etc.), using an intelligent agent to retrieve the service call relationship graph of the business system (such as... Figure 7 The system searches for at least one service matching the request in the link data shown, so that at least one service can indicate which services are involved in the problem indicated by the request. The service call relationship graph is determined based on the operational data of the business system. In response to at least one service including a first service, the system uses an agent to perform code analysis on each call link information (such as the first call link information) corresponding to the first function call relationship graph to obtain the analysis result of the first service, so that the analysis result can indicate the local state of the problem under the first service (such as whether it will be affected by code changes). Based on the analysis result of the first service, the system generates feedback for the request, so that the feedback can indicate the global state of the problem under the business system. In this way, the system can first decompose the problem to a local level through static code analysis results and dynamic code analysis results, and then use an agent to solve the local problem and summarize the results to obtain the global result, so as to improve the request processing effect.

[0123] For the service call relationship diagram of the aforementioned business system, the service call relationship diagram is determined based on the runtime data of the business system, so that the service call relationship diagram can indicate the call relationships between different services presented during the runtime of the business system; moreover, this application does not limit the method of obtaining the service call relationship diagram. For example, it can be implemented using any dynamic code analysis method (such as dynamic call chain acquisition technology based on code instrumentation). As an example, in some scenarios, during the compilation of the business system program, some functions in the source code or bytecode can be directly instrumented (such as...). Figure 7 The instrumentation points shown enable automatic injection of data collection code, and these instrumentations are automatically deployed when the compiled program is deployed, so that the actual execution path (such as service call relationship graphs, dynamic call paths, etc.) can be collected in real time during the business system's runtime. Figure 7 The shown link data allows the real link to at least represent the call chain between different services presented during business system runtime. This enables the agent to analyze the call chain to determine which services are involved in the problem indicated by the current request, and subsequently decompose the processing task for the request into analysis tasks for these services. Therefore, in one possible implementation, the service call relationship graph is automatically collected during business system runtime.

[0124] Regarding the analysis results of the first service mentioned above, the analysis results can represent the local state of the problem indicated by the current request under the first service; moreover, this application does not limit the method of determining the analysis results. For example, it can specifically be: if the problem is detected to involve the first service, the upstream service of the first service, and the downstream service of the first service, the call branch that needs to be analyzed can be identified from the code navigation graph corresponding to the first service based on the service identifier of the upstream service and the service identifier of the downstream service, so that the entry function in the call branch is the function corresponding to the interface used by the upstream service when calling the first service, and the exit function in the call branch points to the downstream service, so that the agent can subsequently analyze and summarize the functions in the call branch to obtain the analysis results of the first service.

[0125] For the feedback to the above request, the feedback is obtained by summarizing and integrating the analysis results of all services involved in the problem indicated by the current request under the business system, so that the feedback can indicate the status of the problem under the business system.

[0126] Based on the aforementioned content regarding business systems, it can be seen that in some scenarios, business systems (such as those provided by...) Figure 7The business system shown may include a code management platform, a code analysis engine, a code compilation module, a service deployment module, and an intelligent agent. The code management platform is configured to record the implementation code of various services provided by the business system. The code compilation module is configured to compile the implementation code of each service. The code analysis engine is configured to perform static code analysis on the implementation code of a service during compilation to obtain a code map (code navigation graph), enabling the code map to present function-level code navigation links and parameter-level field tracing results according to call branching. The service deployment module is configured to deploy services according to the compiled code, so that subsequent data collection (such as dynamic call chains) can be performed during the operation of the business system, allowing the collected data to indicate the service call relationship graph between different services. The agent is configured to, upon detecting a user-triggered request (such as a code change impact analysis request), extract navigation information (e.g., <current service unique identifier #entry function, downstream service unique identifier #exit function>) from the collected data based on the request. It then uses this navigation information to traverse and match the code map to obtain call branches matching the navigation information (e.g., call points, call edges, the code of the function represented by each call point, parameter passing, upstream and downstream processes, etc.). This allows the agent to perform more refined analysis (e.g., code analysis) and aggregation of the functions within the call branches to obtain the response data for the request. Thus, the agent can macroscopically decompose problems based on static and dynamic code analysis results, and locally perform some problem analysis using a large model (e.g., code analysis results of certain functions). By aggregating all analysis results, it can obtain the analysis results of the complete call chain (e.g., the call chain presented between multiple services). Based on this, it can be seen that the business system, at a macro level, fully limits the uncertainty of the large model with the determinism and high accuracy of the code map. This allows the large model to only leverage its intelligent advantages at the micro level to solve some problems. The process of decomposing large and complex tasks is completed based on highly deterministic data (such as code maps, dynamic call chains, etc.). The large model then processes the decomposed smaller tasks and their aggregated processing results. This improves the processing effect of the intelligent agent by raising the lower limit of the large model in actual application scenarios.

[0127] As can be seen, the technical solution provided in this application can achieve the following effects: ① This application constructs a parallel code world (such as a code map including multiple branches) between the source code and the service. This code world is obtained by annotating function nodes, optimizing point-edge relationships, and generating call branches from the entry function to the exit function, enabling the code world to achieve function-level and parameter-level code navigation in the manner of a code map; ② This application uses entry and exit function identification to determine the start and end points of call branches, ensuring that the final call branches accurately represent the actual call chain presented during the current service runtime, overcoming interference from other irrelevant functions; ③ This application improves the accuracy and completeness of call branches by automatically patching edges in broken chain scenarios; ④ This application constructs a code map through a call branch generation algorithm, ensuring that the code map records the actual call chain presented during the runtime of each service; ⑤ This application distinguishes multiple downstream objects that share the same set of entry and exit functions but have different downstream objects by binding parameter information (such as important constants like the unique identifier of the downstream service) to the call branches. Call branches to prevent false alarms and further improve the accuracy of code navigation; ⑥ This application generates cross-repository call branches by building call branches based on local repositories and their dependent libraries, and finally obtains a cross-repository code map, so that cross-repository code navigation can be quickly implemented based on the cross-repository code map to improve navigation efficiency; ⑦ This application determines the downstream service based on the unique identifier of the downstream service bound to the call branch of the current service, takes the exit function as the downstream entry function, realizes the code map and call branch associated with the downstream service, so as to realize the leap of code navigation from single service to multi-service, and finally obtain a cross-service code map, improving code navigation performance; ⑧ The business system provided by this application can automatically evaluate the impact of code changes on some services (such as upstream services) based on call branches and combined with code change requests, improving the accuracy and efficiency of evaluation; The business system can present these call branches to users in a visual way, so that users can quickly understand the call paths presented by each service in the business system, improving code understanding efficiency; The business system can eliminate large models (such as...) from a macro perspective based on the determinism of the code navigation map. Figure 7 The uncertainty of the intelligent agent (illusion) is used to guide the large model to analyze problems at the micro level, so as to avoid the large model from making up stories and distorting the results, and thus improve the performance lower limit of the large model.

[0128] Based on the code analysis method provided in the embodiments of this application, the embodiments of this application also provide a code analysis device, which is described below in conjunction with... Figure 8 Explanation and clarification will be provided. Among them, Figure 8This is a schematic diagram of a code analysis device provided in an embodiment of this application. It should be noted that for technical details of the code analysis device provided in this embodiment, please refer to the relevant content of the code analysis method above.

[0129] like Figure 8 As shown, the code analysis device 800 provided in this application embodiment includes:

[0130] The determining unit 801 is used to determine the function set corresponding to the first service based on the code file of the first service;

[0131] Construction unit 802 is used to construct a first function call relationship graph based on the function set;

[0132] The identification unit 803 is used to identify the first entry function and the first exit function from the first function call relationship graph;

[0133] The generation unit 804 is used to obtain first call chain information based on the first entry function, the first exit function and the first function call relationship diagram, wherein the first call chain information indicates the function call chain between the first entry function and the first exit function.

[0134] In one possible implementation, the function set includes a first set and a second set, wherein the functions in the first set are functions included in the code file, and the functions in the second set are functions directly or indirectly called by the functions in the first set; the entry function is located in the first set; the exit function is located in the first set, or the exit function is located in the second set.

[0135] In one possible implementation, the code analysis device 800 further includes: a splicing unit, configured to determine third call link information based on the first call link information and the second call link information in response to the first exit function being the same as the second entry function in the second call link information, wherein the second call link information is generated based on the function set corresponding to the second service, the third entry function in the third call link information is the first entry function, and the third exit function in the third call link information is the second exit function in the second call link information.

[0136] In one possible implementation, the generation unit 804 is further configured to: determine parameter information corresponding to the first call chain information based on the first function call relationship graph, wherein the parameter information includes an object identifier, the object identifier indicating the downstream object pointed to by the first exit function; and the parameter information and the first call chain information are stored in correspondence.

[0137] In one possible implementation, the construction unit 802 is further configured to: in response to detecting that the first function in the first function call graph satisfies the occurrence condition corresponding to the preset chain break type, process the first function call graph according to the edge-filling logic corresponding to the preset chain break type.

[0138] In one possible implementation, the construction unit 802 is specifically used to: perform class hierarchy analysis on the function set to obtain a first function call relationship graph;

[0139] The construction unit 802 is further configured to: select at least one function from the function set; and perform variable type analysis on the first function call relationship graph based on the at least one function.

[0140] In one possible implementation, the function set includes a first set and a second set; the selection process of the at least one function includes: determining a second function from the first set, wherein the second function does not satisfy a preset exclusion condition; determining a third function from the second set, wherein the third function exists in the first function call relationship graph; and determining the at least one function based on the second function and the third function.

[0141] In one possible implementation, the generation unit 804 is specifically used to: add a marker corresponding to the first entry function and a marker corresponding to the first exit function to the first function call relationship graph; and determine the first call chain information from the first function call relationship graph.

[0142] In one possible implementation, in response to a third service calling the first service through an interface, the first entry function is the function corresponding to the interface; the first exit function is configured to point to the second service or component called by the first service.

[0143] In one possible implementation, the code analysis device 800 further includes:

[0144] A lookup unit is configured to, in response to receiving a request triggered by a business system, use an intelligent agent to look up at least one service matching the request from the service call relationship graph of the business system, wherein the service call relationship graph is determined based on the operating data of the business system;

[0145] Analysis unit, configured to, in response to the at least one service including the first service, use the agent to perform code analysis on each call chain information corresponding to the first function call relationship graph to obtain the analysis result of the first service;

[0146] The aggregation unit is used to generate feedback for the request based on the analysis results of the first service.

[0147] It should be noted that the working principle and effects of the code analysis device 800 described above can be found in similar code analysis methods described above, and will not be repeated here for the sake of brevity.

[0148] In addition, this application also provides an electronic device, the device including a processor and a memory: the memory is used to store instructions or computer programs; the processor is used to execute the instructions or computer programs in the memory, so that the electronic device performs any implementation of the code analysis method provided in this application.

[0149] See Figure 9 The diagram illustrates a structural schematic of an electronic device 900 suitable for implementing embodiments of the present disclosure. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 9 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0150] like Figure 9 As shown, electronic device 900 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 902 or a program loaded from storage device 908 into random access memory (RAM) 903. RAM 903 also stores various programs and data required for the operation of electronic device 900. The processing device 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0151] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic device 900 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 9 An electronic device 900 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0152] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 909, or installed from a storage device 908, or installed from a ROM 902. When the computer program is executed by a processing device 901, it performs the functions defined in the methods of embodiments of this disclosure.

[0153] The electronic device provided in this embodiment belongs to the same inventive concept as the method provided in the above embodiments. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0154] This application also provides a computer-readable medium storing instructions or computer programs that, when executed on a device, cause the device to perform any implementation of the code analysis method provided in this application.

[0155] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0156] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0157] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A code analysis method characterized by, The method comprises: determining a function set corresponding to the first service according to a code file of the first service; constructing a first function call relationship graph according to the function set; identifying a first entry function and a first exit function from the first function call relationship graph; obtaining first call link information according to the first entry function, the first exit function and the first function call relationship graph, the first call link information indicating a function call link between the first entry function and the first exit function.

2. The method of claim 1, wherein, The function set comprises a first set and a second set, functions in the first set are functions included in the code file, and functions in the second set are functions directly or indirectly called by functions in the first set; The entry function is located in the first set; The exit function is located in the first set, or the exit function is located in the second set.

3. The method of claim 1, wherein, The method further comprises: in response to the first exit function being the same as a second entry function in second call link information, determining third call link information according to the first call link information and the second call link information, the second call link information being generated based on a function set corresponding to a second service, a third entry function in the third call link information being the first entry function, and a third exit function in the third call link information being a second exit function in the second call link information.

4. The method of claim 1, wherein, The method further comprises: determining parameter information corresponding to the first call link information according to the first function call relationship graph, the parameter information comprising an object identifier, the object identifier indicating a downstream object pointed to by the first exit function; The parameter information and the first call link information are stored correspondingly.

5. The method of claim 1, wherein, Before the first call link information is obtained according to the first entry function, the first exit function and the first function call relationship graph, the method further comprises: in response to detecting that a first function in the first function call relationship graph satisfies an occurrence condition corresponding to a preset chain breaking type, processing the first function call relationship graph according to a rimming logic corresponding to the preset chain breaking type.

6. The method of claim 5, wherein, The first function call relationship graph is constructed according to the function set, comprising: performing hierarchical analysis on the function set to obtain the first function call relationship graph; Before the first function call relationship graph is processed according to the rimming logic corresponding to the preset chain breaking type, the method further comprises: selecting at least one function from the function set; and performing variable type analysis processing on the first function call relationship graph according to the at least one function.

7. The method of claim 6, wherein, The function set comprises a first set and a second set; The at least one function is selected from the function set, comprising: a second function determined from the first set, the second function not satisfying a preset exclusion condition; a third function determined from the second set, the third function existing in the first function call relationship graph; determining the at least one function according to the second function and the third function.

8. The method of claim 5, wherein, The first calling link information is obtained according to the first entry function, the first exit function and the first function call relationship graph, and the first calling link information comprises: The first entry function corresponding mark and the first exit function corresponding mark are added in the first function call relationship graph; The first calling link information is determined from the first function call relationship graph.

9. The method of claim 1, wherein, The first entry function is a function corresponding to an interface in response to that a third service calls the first service through the interface; The first exit function is configured to point to a second service or a component called by the first service.

10. The method according to any one of claims 1 to 9, characterized in that, The method further comprises: In response to receiving a request triggered for a business system, an agent is used to find at least one service matched with the request from a service call relationship graph of the business system, and the service call relationship graph is determined based on running data of the business system; In response to that the at least one service comprises the first service, the agent is used to code analyze each calling link information corresponding to the first function call relationship graph to obtain an analysis result of the first service; A feedback for the request is generated according to the analysis result of the first service.

11. A code analysis apparatus characterized by comprising: Comprise: The determining unit is configured to determine a function set corresponding to the first service according to a code file of the first service; The constructing unit is configured to construct a first function call relationship graph according to the function set; The identifying unit is configured to identify a first entry function and a first exit function from the first function call relationship graph; The generating unit is configured to obtain first calling link information according to the first entry function, the first exit function and the first function call relationship graph, and the first calling link information indicates a function calling link between the first entry function and the first exit function.

12. An electronic device, comprising: The device comprises a processor and a memory; The memory is configured to store instructions or computer programs; The processor is configured to execute the instructions or computer programs in the memory, so that the electronic device executes the method in any one of claims 1-10.

13. A computer readable medium characterized by The computer readable medium stores instructions or computer programs, and when the instructions or computer programs run on the device, the device executes the method in any one of claims 1-10.

14. A computer program product, characterised in that, It comprises a computer program carried on a non-transitory computer readable medium, and the computer program comprises program codes for executing the method in any one of claims 1-10.

Images