A code detection method and apparatus

Abstract

The application provides a code detection method and device. In the application, the detection of the code is no longer limited to the independent detection of a local code, but in the full code, a function to be detected is determined; in the full code, a target function having a calling relationship with the function to be detected is determined, and the calling relationship between the function to be detected and the target function is determined; based on the calling relationship, whether the calling between the function to be detected and the target function will cause an exception is detected. The application takes the calling relationship between the functions as a structured context, and automatically detects the exception caused by the calling between the functions. In this way, deep defects caused by the calling between the functions can be detected, and the comprehensiveness of the code detection is improved. Furthermore, the application determines a global scheduling chain related to the function to be detected through the full code, and the calling chain is complete, so that the missing detection rate can be reduced, and the detection accuracy can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a code detection method and apparatus. Background Technology

[0002] In the R&D system of terminal software, the code of terminal software is delivered in the form of compiled products, such as delivered to the terminal (the device used by the user) for installation and use. Therefore, the code quality of terminal software directly determines the operational stability, security and user experience of terminal software.

[0003] Because terminal software is deployed in an isolated environment, it lacks the hot-fix or real-time rollback capabilities common on the server side. Therefore, once the terminal software code exposes quality problems such as logical defects, resource management errors, or concurrency anomalies after delivery, it often leads to long repair cycles, high rollback costs, and a wide range of impacts. In severe cases, it may cause user churn and damage to the reputation of the software brand.

[0004] Therefore, establishing an efficient and accurate CR (Code Review) mechanism has become a key step in ensuring the code quality of terminal software.

[0005] In recent years, AI (Artificial Intelligence) has made continuous progress in code semantic understanding, context-aware reasoning, and defect pattern recognition, providing a technological foundation for achieving intelligent and automated code inspection. Summary of the Invention

[0006] This application provides a code detection method and apparatus.

[0007] In a first aspect, this application discloses a code detection method, the method comprising: In the full code, identify the function to be tested; In the full code, a target function with a calling relationship with the function to be detected is identified, and the calling relationship between the function to be detected and the target function is determined; Based on the call relationship, it is determined whether the call between the function to be detected and the target function will cause an exception.

[0008] Secondly, this application discloses a code detection device, the device comprising: The first determination module is used to identify the function to be detected in the entire code. The second determining module is used to determine, within the full code, a target function that has a calling relationship with the function to be detected, and to determine the calling relationship between the function to be detected and the target function; The detection module is used to detect whether the call between the function to be detected and the target function will cause an exception based on the call relationship.

[0009] Thirdly, this application discloses an electronic device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the methods shown in any of the foregoing aspects.

[0010] Fourthly, this application discloses a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the methods shown in any of the foregoing aspects.

[0011] Fifthly, this application discloses a computer program product in which, when the instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to perform the methods shown in any of the foregoing aspects.

[0012] This application has the following advantages: In this application, code detection is no longer limited to detecting a single line of code independently, but rather involves identifying the function to be detected within the entire code; identifying the target function that has a calling relationship with the function to be detected within the entire code, and determining the calling relationship between the function to be detected and the target function; and based on the calling relationship, detecting whether the call between the function to be detected and the target function will cause an exception.

[0013] As can be seen, this application uses the calling relationship between functions as a structured context to automatically detect exceptions caused by function calls. In this way, deep defects caused by function calls can be detected, improving the comprehensiveness of code detection.

[0014] Secondly, this application determines the global scheduling chain involved in the function to be detected by using the full code, and the complete call chain can reduce the false negative rate and improve the accuracy of detection. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of a code detection method according to this application.

[0017] Figure 2 This is a flowchart of a code detection method according to this application.

[0018] Figure 3 This is a flowchart of a code detection method according to this application.

[0019] Figure 4 This is a flowchart of a code detection method according to this application.

[0020] Figure 5 This is a schematic diagram of a code detection architecture proposed in this application.

[0021] Figure 6 This is a flowchart of a code detection method according to this application.

[0022] Figure 7 This is a flowchart of a code detection method according to this application.

[0023] Figure 8 This is a structural block diagram of a code detection device according to this application.

[0024] Figure 9 This is a structural block diagram of a device according to this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to facilitate a full understanding of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. This specification can be implemented in many other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific embodiments disclosed below. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort should fall within the scope of protection of this specification.

[0026] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments. Conversely, multiple steps described in this specification may be combined into a single step in other embodiments.

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

[0028] Currently, some AI-driven CR tools have emerged on the market for detecting the code of terminal software.

[0029] However, the inventors conducted a statistical analysis on the "terminal software whose code was detected by an AI-driven CR tool" and found that the "terminal software whose code was detected by an AI-driven CR tool" still experienced crashes, freezes, and memory leaks during operation.

[0030] Furthermore, the inventors analyzed the reasons why "even after the terminal software's code was detected by the AI-driven CR tool, software crashes, lag, and memory leaks still occurred during operation," and discovered that: In many cases, crashes, freezes, and memory leaks are caused by defects such as inconsistent states in asynchronous callbacks, unreleased resources, null pointer dereferences, and misuse of object lifecycles.

[0031] Furthermore, the inventors discovered that "inconsistent states, logical errors, resource leaks, unreleased resources, null pointer dereferencing, and misuse of object lifecycles in asynchronous callbacks" often involve function calls in terminal software, especially in complex function call chains. Complex function call chains include: cross-function and cross-module call chains in the code (functions can be successfully called, but exceptions may occur after the call).

[0032] However, existing AI-driven code completion (CR) tools generally focus on independent inspection of individual lines of code, mainly checking the syntactic compliance of individual lines of code, and lack the ability to model the overall structure of the entire code. For example, they lack the ability to model the call relationships between functions, and therefore cannot model the overall structure of the entire code. Thus, they cannot inspect the code based on the overall structure of the entire code, such as detecting exceptions caused by function calls, and accurately identifying deep-seated defects caused by function calls. The inventors discovered that deep-seated defects caused by function calls are the main cause of terminal software crashes, lag, and memory leaks.

[0033] In view of this, and to address the aforementioned technical limitations, this solution proposes a code detection scheme based on function call chains.

[0034] This scheme accurately extracts structured context information such as function call paths, parameter passing chains, and control dependencies by constructing a full-range function call chain of the software code.

[0035] By using function call chains as context, the intelligent detection model can be guided to perform fine-grained semantic understanding and potential risk prediction at the function level. Compared to existing AI-driven code execution (CR) tools, this solution uses the call relationships between functions as a structured context to automatically detect exceptions caused by function calls. This allows for the detection of deep-seated defects caused by function calls, improving the comprehensiveness of code inspection and enhancing the ability to detect deep-seated defects in code under real-world execution scenarios. As a result, it is more closely aligned with real-world engineering scenarios, enabling efficient interception of high-risk issues in the early stages of development and systematically enhancing the reliability, stability, security, and delivery efficiency of terminal software code.

[0036] Before introducing the solution of this application, the technical terms that may be involved in this application will be explained.

[0037] Terminal code refers to the source code of client applications running on user devices. It is usually compiled and distributed in binary form, and is characterized by high stability requirements, low fault tolerance, and difficulty in hot-fixing.

[0038] Static analysis is a technique that extracts information such as program structure, control flow, data flow, and call relationships by parsing source code or intermediate representations without executing the program. It is the foundation for constructing function call chains.

[0039] Function call chain: refers to the sequence of function calls or call relationship graphs identified through static analysis starting from a certain entry point in a program. It is used to depict the dependencies between methods, data flow, and execution context, and is key structural information for understanding code behavior and potential risks.

[0040] Intelligent Code Review: Utilizes artificial intelligence (AI) to automate the analysis and evaluation of source code. It not only covers syntax and style checks, but also combines contextual semantics to identify logical errors, security vulnerabilities, and architectural issues, achieving a deeper level of quality assurance.

[0041] Method-level review: This is a granularity of review that uses a single function or method as the basic unit of analysis. It conducts a comprehensive quality and risk assessment based on the internal implementation logic and the external calling context (such as the caller, callee, and parameter passing path).

[0042] See Figure 1 This application illustrates a code detection method, which may include: In step S101, the function to be detected is determined in the full code.

[0043] In this application, "full code" includes: all the code in the code of a software, or: all the code in a software development project.

[0044] Each function in the full code can be treated as a function to be detected, and it can be detected by the detection method of this application. For example, the following steps S102 to S103 are performed on it.

[0045] For details of this step, please refer to the embodiments shown later, which will not be described in detail here.

[0046] In step S102, in the full code, the target function that has a calling relationship with the function to be detected is determined, and the calling relationship between the function to be detected and the target function is determined.

[0047] In this application, if function B is called in the code of function A, the calling relationship between function A and function B can be: function A directly calls function B.

[0048] Furthermore, if function B calls function C within its code, then after function A calls function B, function B will also call function C. Therefore, the calling relationship between function B and function C can be: function B directly calls function C.

[0049] The calling relationship between function A and function C can be: function A indirectly calls function C (function A calls function C through function B, therefore, function A does not directly call function C, but rather indirectly calls function C).

[0050] Therefore, in one embodiment, the target function can be a function that calls the function to be detected (an upstream function of the function to be detected). The function that calls the function to be detected includes: a function that directly calls the function to be detected, and / or a function that indirectly calls the function to be detected (that is, the target function indirectly calls the function to be detected through other functions).

[0051] The function that calls the function to be detected can be one or more. Thus, the calling relationship between the function to be detected and the target function includes: the target function calling the function to be detected. Specifically, this can include: the target function directly calling the function to be detected, or the target function indirectly calling the function to be detected.

[0052] Alternatively, in another embodiment, the target function can be a function called by the function to be detected (a downstream function of the function to be detected). The functions called by the function to be detected include: functions directly called by the function to be detected, and / or functions indirectly called by the function to be detected (that is, the function to be detected indirectly calls the target function through other functions).

[0053] The function to be detected can call one or more functions. Thus, the calling relationship between the function to be detected and the target function includes: the function to be detected calling the target function. Specifically, this can include: the function to be detected directly calling the target function, or the function to be detected indirectly calling the target function.

[0054] For details of this step, please refer to the embodiments shown later, which will not be described in detail here.

[0055] In step S103, based on the calling relationship, it is detected whether the call between the function to be detected and the target function will cause an exception.

[0056] In one embodiment, in response to the calling relationship between the target function and the function to be detected, the target function calls (including direct or indirect calls) the function to be detected.

[0057] Specifically, to detect whether a call between the function to be detected and the target function will cause an exception, it can be to detect whether a call from the target function to the function to be detected will cause an exception.

[0058] For example, after the target function successfully calls the function to be tested, will the execution logic (implementation logic) of the function to be tested itself cause an exception? If the execution logic (implementation logic) of the function to be tested itself has defects, an exception will be caused; otherwise, if the execution logic (implementation logic) of the function to be tested itself has no defects, an exception will not be caused.

[0059] For example, if the function under test executes a network request on the main thread after the target function successfully calls the function under test, it will trigger an "Application Not Responding (ANR)" exception.

[0060] For example, if the function under test opens a file but does not close it after the target function successfully calls the function under test, it will trigger a "memory leak or memory crash" exception.

[0061] For example, if the target function successfully calls the function under test, and the function under test modifies a shared variable without locking it, a "concurrency conflict" exception will be triggered.

[0062] Alternatively, in another embodiment, in response to the calling relationship between the target function and the function to be detected, the function to be detected calls (including direct or indirect calls) the target function.

[0063] Specifically, to detect whether the call between the function to be detected and the target function will cause an exception, it can be to detect whether the call between the function to be detected and the target function will cause an exception.

[0064] In this way, by identifying incompatible changes in advance, cross-module cascading failures caused by local optimizations can be effectively prevented.

[0065] For example, in one embodiment, the calling relationship between the function to be detected and the target function is: the function to be detected calls the target function.

[0066] In a scenario where the function to be tested calls the target function, the function to be tested needs to pass a parameter P that cannot be null to the target function. However, the function to be tested may not assign a value to parameter P in some logical branches, or the function to be tested may not pass parameter P to the target function in some logical branches. However, the target function may not have any logic to check whether parameter P is null. In this case, the target function will receive a non-null parameter P passed by the function to be tested, and will throw a null pointer exception.

[0067] Therefore, it is necessary to count all call paths of the function under test to the target function, and check whether the parameter P transmitted by the function under test to the target function in each call path may be empty (this can be done through data flow analysis). Also, check whether the signature or implementation of the target function has logic to determine whether the parameter P is empty and whether it has a default value for the parameter P. If there is at least one call path in which the parameter P transmitted by the function under test to the target function may be empty, the target function does not have logic to determine whether the parameter P is empty, and the target function does not have a default value for the parameter P, then it is determined to be an anomaly of "introducing a non-empty parameter without providing a default value".

[0068] In another embodiment, the calling relationship between the function to be detected and the target function is: the target function calls the function to be detected. The function to be detected is the function to which the modified code belongs, and the function to which the corresponding code before the modification belongs is assumed to be the original function.

[0069] In scenarios where the target function calls the source function, the target function needs to use the return value of the source function for the next operation. If the source function fails to process the data, it will return an empty return value "null", indicating "failure". Based on the return value "null", the target function will retry according to the retry logic of the target function.

[0070] After modifying the code in the source function to obtain the function to be tested, even if the data processing fails, it will not return an empty return value "null", but will only return a non-empty return value. However, the target function will receive a non-empty return value, and will assume that the function to be tested has successfully processed the data (when in fact the function to be tested has failed to process the data). As a result, the target function will skip the retry logic and not retry, leading to a logical error.

[0071] To this end, we can count the return values ​​of various types of the function to be tested and check whether each type of return value has corresponding processing logic in the target function. If at least one type of return value does not have corresponding processing logic in the target function, it is determined to be an "abnormality of semantic mismatch".

[0072] In another embodiment, the calling relationship between the function to be detected and the target function is: the target function calls the function to be detected. The function to be detected is the function to which the modified code belongs, and the function to which the corresponding code before the modification belongs is assumed to be the original function.

[0073] In scenarios where the target function calls the source function, a logical branch of the source function might throw an exception, such as an IOException (an exception type). The target function has exception handling logic for IOException, enabling it to catch and handle the IOException. After modifying the code in the source function to obtain the function to be tested, the function to be tested throws a RuntimeException (another exception type, different from IOException). However, the target function, using the exception handling logic for IOException, cannot catch the RuntimeException, causing the exception thrown by the function to be tested to go unhandled, potentially leading to program crashes.

[0074] Therefore, it is possible to detect whether the type of the exception caught in the target function is the same as the type of the exception thrown by the function to be detected. If they are different, it is determined to be an exception that "changes the type of exception thrown".

[0075] In this application, code detection is no longer limited to detecting a single line of code, but rather involves identifying the function to be detected within the entire codebase. Within the entire codebase, target functions with which the function to be detected has a call relationship are identified, and the call relationship between the function to be detected and the target function is determined. Based on this call relationship, it is determined whether the calls between the function to be detected and the target function will cause exceptions.

[0076] As can be seen, this application uses the calling relationship between functions as a structured context to automatically detect exceptions caused by function calls. In this way, deep defects caused by function calls can be detected, improving the comprehensiveness of code detection.

[0077] Secondly, this application determines the global scheduling chain involved in the function to be detected by using the full code, and the complete call chain can reduce the false negative rate and improve the accuracy of detection.

[0078] In addition, this application does not use a line of code as the smallest detection unit, but uses a "function" as the smallest detection unit. When detecting whether calls between functions will cause exceptions, it can combine the internal implementation of the function itself with the external caller (or external callee) to detect whether calls between functions will cause exceptions. This enables fine-grained detection of complex logic such as resource management, state transition, and exception propagation, thereby improving detection accuracy.

[0079] In one embodiment of this application, see [link to embodiment]. Figure 2 Step S102 includes: In step S201, the full call relationships between multiple functions in the full code are obtained.

[0080] In this application, when obtaining the full call relationship between multiple functions in the full code, the full call relationship between multiple functions in the full code can be generated in real time.

[0081] When generating the full call relationship between multiple functions in the full code, the full code can be scanned, and then based on the AST (Abstract Syntax Tree), a metadata table of functions in the full code and a function call relationship table of the full code can be constructed. Based on the metadata table of functions in the full code and the function call relationship table of the full code, the full call relationship between multiple functions in the full code can be obtained.

[0082] The metadata table of the functions in the full code contains the complete signature of each function in the full code (including the class name of the class to which the function belongs, the function name, the types of the input parameters, the type of the return value, and the access modifiers of the function).

[0083] The function call relationship table in the full code contains the complete signatures of other functions that are directly called inside each function in the full code, forming fine-grained call edges.

[0084] Based on the metadata table of functions in the full code and the function call relationship table of the full code, a topology structure of the call relationship of the full code can be constructed (the topology structure can be a topology graph, such as a function call graph). The topology structure includes nodes and edges. Nodes can be functions (e.g., represented by the function name). If a node calls another node, there is an edge between the two nodes. The edge has an arrow pointing from one node to the other node, which is used to indicate that one node calls another node. The topology structure of the call relationship is determined as the full call relationship between multiple functions in the full code.

[0085] Thus, the topology supports efficient querying of the upstream callers of any function (i.e., other functions that actively call this function, and this function being called by those other functions), as well as efficient querying of the call relationship between any function and its upstream callers, efficient querying of the downstream callees of any function (i.e., other functions that actively call this function, and those other functions being called by this function), and efficient querying of the call relationship between any function and its downstream callers.

[0086] However, when there are many functions in the full code and the calling relationships between multiple functions are complex, the process of generating the full calling relationships between multiple functions in the full code in real time is time-consuming and consumes too many system resources.

[0087] Therefore, in another embodiment of this application, the full call relationship between multiple functions in the full code can be generated offline in advance and stored for subsequent calls.

[0088] Therefore, when obtaining the full call relationship between multiple functions in the full code, the stored full call relationship can be obtained.

[0089] This embodiment avoids generating the full call relationships between multiple functions in the full code every time it is necessary to obtain them, thus saving network resources. It can directly obtain the full call relationships between multiple functions in the full code that were previously generated and stored, improving the acquisition speed and saving time.

[0090] By providing the complete call relationships between multiple functions in the full code, a complete upstream call entry point and downstream dependency path can be provided, thus providing a complete call chain related to the function to be detected. This provides full information, overcoming the shortcomings of traditional methods that only detect lines of code and have only local code information (only a local view), improving the completeness of anomaly detection, reducing the false negative rate, improving the accuracy of detecting deep defects across functions and modules, and improving the detection accuracy.

[0091] In step S202, based on the full call relationship, the target function that has a call relationship with the function to be detected is determined, and the call relationship between the function to be detected and the target function is determined.

[0092] In one embodiment, the nodes of the function to be detected can be indexed in the aforementioned topology, and then the target nodes of the function call can be indexed.

[0093] For example, traverse node 1, which has an edge between it and the node of the function to be tested. The arrow of the edge between the node of the function to be tested and node 1 points from the node of the function to be tested to node 1. Node 1 is the node directly called by the function to be tested.

[0094] Traverse the nodes that have an edge between them and node 1 (if it exists). The arrow of the edge between node 1 and node 2 points from node 1 to node 2. Node 2 is the node directly called by the function of node 1, the node indirectly called by the function to be tested, and so on, until the traversed nodes have no "arrow pointing outward" edges.

[0095] All nodes traversed are used as target nodes for the function calls to be detected.

[0096] In another embodiment, the nodes of the function to be detected can be indexed in the aforementioned topology, and then the target nodes of the function call can be indexed.

[0097] For example, traverse node 1, which has an edge between it and the node of the function to be tested. The arrow of the edge between the node of the function to be tested and node 1 points from node 1 to the node of the function to be tested. The function to be tested is the node directly called by node 1.

[0098] Traverse the nodes that have an edge between them and node 1 (if it exists). The arrow of the edge between node 1 and node 2 points from node 2 to node 1. Node 1 is the node whose function is directly called by node 2. The function to be tested is the node whose function is indirectly called by node 2. And so on, until the traversed node has no "arrow pointing to the edge".

[0099] Each node traversed is used as the target node for calling the function to be tested.

[0100] In step S101, when determining the function to be detected in the full code, in one embodiment of this application, each function in the full code can be used as the function to be detected and detected by the detection method of this application. However, sometimes the call chains involved in many functions in the full code have already been detected by the detection method of this application in the previous round of detection, and the detection result is no abnormality. Therefore, it is unnecessary to repeatedly detect the call chains involved in each function in the full code, otherwise it will consume too much system resources.

[0101] Therefore, in another embodiment of this application, if the call chains of most functions in the full code or the call chains of each function have been detected by the detection method of this application and the detection results are all normal, then the exception caused by the call between functions often occurs in the scenario where a function is modified. The modification of a function includes: at least a part of the function's code is modified, at least a part of the function's code is deleted, and at least a part of the function's code is added. Secondly, the exception caused by the call between functions often occurs in the scenario where a function is a newly added function. The above scenarios are all scenarios where part of the code in the full code is modified.

[0102] Therefore, when all the code is modified, it is necessary to designate the function to which the modified code belongs as the function to be detected, so that the call chain involved can be detected by the detection method of this application. The call chain involved by functions other than the function to which the modified code belongs in the full code can be ignored, so as to avoid consuming too much system resources and improve the efficiency of code detection.

[0103] Specifically, in one embodiment of this application, see [link to relevant documentation]. Figure 3 Step S101 includes: In step S301, the changed code is identified in the full code.

[0104] All code in the line containing the modified code can be considered as changed code. All code in the line containing the deleted code (even if only a portion of the line was deleted) can be considered as changed code. All code in the line containing the added code can be considered as changed code.

[0105] Changes may involve changes to variable declarations, function calls, and control flow.

[0106] These changes may alter the internal logic of a function, add or delete content in the function body, or adjust the function signature (such as adding or removing parameters or changing the return value).

[0107] In one scenario, after a user makes full changes to the code (additions, deletions, or modifications, etc.) on their terminal, they can submit a code change request to the electronic device, so that the electronic device can synchronously update the full code (the electronic device is used to store the full code) according to the code change request.

[0108] Afterwards, the user can manually trigger the detection to make the electronic device perform the step of "identifying the changed code in the full codebase". However, the fact that the electronic device needs to manually trigger the "identifying the changed code in the full codebase" step makes the user operation cumbersome and the user experience poor. Moreover, sometimes the user may forget to trigger the detection after submitting the code change request to the electronic device, resulting in the electronic device not triggering the "identifying the changed code in the full codebase" step and the inability to detect the changed code.

[0109] Therefore, in another embodiment of this application, in response to receiving a code change request, the code to be changed is determined in the full code, and the code change request is entered after the full code has been changed.

[0110] In this embodiment, upon receiving a code change request, detection is automatically triggered, and the electronic device automatically executes the step of "identifying the changed code in the full code". This automatically triggers the detection of the changed code without relying on manual triggering by the user, simplifying user operations and improving user experience. Furthermore, it ensures that the changed code can be detected after the user submits a code change request to the electronic device using the terminal.

[0111] In step S302, the function to which the changed code belongs is determined in the full code.

[0112] In the full codebase, it is already determined which functions contain which code (i.e., which code is input to which functions). Within the full codebase, it is determined which function's code the modified code belongs to, thus identifying the function to which the modified code belongs.

[0113] In one example, both the full code and the modified code can be input into the intelligent determination model, so that the intelligent determination model can determine the function to which the modified code belongs from the full code.

[0114] In this application, identifying a function requires the use of the function's signature (e.g., function name, input parameters, and return type) and scope delimitation (e.g., the range of curly braces in the code). The modified code is merely a code fragment. Therefore, based solely on this modified code fragment, it may be impossible to determine where a function begins and ends (especially if the modified code is located in the middle of the function's code), and consequently, it may be impossible to determine the function to which the modified code belongs.

[0115] Therefore, in this application, by using the full code, the intelligent determination model can accurately parse the abstract syntax tree (AST) of the full code, identify the declaration keywords of functions in the full code, track the scope boundaries (e.g., the scope of curly braces in the code), and thus determine the start and end boundaries of each function in the full code, thereby accurately determining the function to which the modified code belongs.

[0116] In this embodiment, the metadata obtained can be the metadata of the function to which the modified code belongs. For example, the intelligent determination model output can be the metadata of the function to which the modified code belongs.

[0117] The metadata of the function to which the modified code belongs includes: the class name of the class to which the modified code belongs, the function name of the modified code, the input parameter types of the modified code, the return value type of the modified code, the access modifier of the modified code, and the path of the file package where the modified code is located.

[0118] In step S303, the function to be detected is determined based on the function to which the changed code belongs.

[0119] For example, the function to which the changed code belongs is identified as the function to be detected.

[0120] This embodiment enables the intelligent deterministic model to obtain, parse, and understand the entire code, acquiring comprehensive information about it. This ensures that subsequent code detection is always performed on complete, independent functions as the basic unit, effectively avoiding misjudgments or missed detections caused by the lack of comprehensive information (full context) in traditional line-level or fragment-level code detection. It forms a full-link intelligent detection system covering "change point—call chain—impact surface".

[0121] This application can also avoid redundant analysis of functions whose code has not been changed, focusing on functions that may be affected, thus significantly improving the efficiency and targeting of detection.

[0122] In one embodiment of this application, see [link to embodiment]. Figure 4 Step S103 includes: In step S401, the metadata of the function to be detected and the metadata of the target function are obtained.

[0123] The metadata of a function includes: the function's identity (e.g., the function name, the class name of the class to which the function belongs, the packet path of the data package containing the function, and the file path of the file containing the function, used to locate the function), the function's thread context (e.g., whether it is executed in a background thread or in the main thread, used to determine whether the thread is compliant), performance impact (e.g., whether it is a time-consuming operation, such as large file parsing or complex calculations, whether it is a blocking I / O operation, such as file reading and writing or network requests, and whether it is a database operation), exception handling methods (e.g., whether it throws undeclared exceptions, whether it catches exceptions, and whether there is logic for handling exceptions), resource usage (e.g., whether resources that need to be manually released have been allocated, used to determine whether corresponding release logic is needed), call constraints (e.g., whether non-null parameters, specific permissions, or initialization are required, used to determine whether the caller meets the conditions), and call frequency characteristics (e.g., whether it is marked as a high-frequency call, such as >10 calls per second), etc.

[0124] Therefore, function metadata can provide the calling context (e.g., if a function runs on the UI thread, it cannot call blocking I / O functions), can indicate potential risk tendencies (e.g., high-frequency calls + failure to release resources may lead to resource leaks), reflect the developer's intent, declare execution prerequisites (e.g., it needs to be executed on a background thread, or it needs a network connection), expose dangerous behaviors (e.g., blocking threads, modifying the UI, or throwing exceptions), and specify calling constraints (e.g., input parameters cannot be empty, or the user needs to have calling permissions).

[0125] In step S402, based on the metadata of the function to be detected, the metadata of the target function, and the call relationship, it is determined whether the call between the function to be detected and the target function will cause an exception.

[0126] By analyzing the metadata of the function under test and the target function, we can obtain the execution environment and risk profile of the caller (the basis for determining whether the call is safe) and the behavioral contract and security risks of the callee (the basis for determining whether the call should be made in this way). By combining the metadata of the function under test and the target function with the call relationship, we can accurately identify exceptions caused by calls, such as thread mismatch, resource leaks, missing exception handling, and incorrect experimental configuration, thereby improving the accuracy of detection.

[0127] In one embodiment of this application, when detecting whether a call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship, the metadata of the function to be detected, the metadata of the target function, and the call relationship can all be input into the intelligent detection model as input data, so that the intelligent detection model can detect whether a call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0128] Intelligent detection models include: large language models, convolutional neural network models, random forest models, or graph neural network models, etc.

[0129] This application utilizes an intelligent detection model to improve the accuracy of detecting whether calls between the function to be detected and the target function will cause anomalies.

[0130] However, in scenarios where general intelligent detection models need to detect whether calls between the target function and the function to be detected will cause anomalies, their detection behavior sometimes diverges and exhibits hallucinations. Sometimes, when lacking constraints, these models may "fabricate" seemingly reasonable but incorrect detection results based on statistical patterns, generating a large number of low-confidence or irrelevant false alarms. For example, sometimes the detection may not target the expected anomaly types (e.g., technicians expect the intelligent detection model to perform certain types of detection), lacking constraints and resulting in detection results that do not involve the expected anomaly types, thus failing to meet expectations, leading to a high false alarm rate and poor interpretability. This not only reduces developers' willingness to adopt it but also increases the burden of manual review, weakening the value of automation.

[0131] Therefore, in another embodiment of this application, the metadata of the function to be detected, the metadata of the target function, and the call relationship are all input data into the intelligent detection model. This allows the intelligent detection model to obtain preset detection rules when detecting whether the call between the function to be detected and the target function will cause anomalies based on the metadata of the function to be detected, the metadata of the target function, and the call relationship. The preset detection rules are also input as prompt words into the intelligent detection model, so that the intelligent detection model uses the preset detection rules as prompt words to detect whether the call between the function to be detected and the target function will cause anomalies based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0132] In one embodiment, a preset detection rule is defined as follows: detect whether a blocking I / O operation is called inside the function. If a blocking I / O operation is called inside the function, detect whether the blocking I / O operation is not executed in a background thread. If the blocking I / O operation is not executed in a background thread, it may cause the application to respond abnormally. Therefore, it can be determined that there is an exception of "UI thread blocking I / O".

[0133] In another embodiment, a preset detection rule specifically includes: detecting whether an "external resource," such as an external file or database query result, is opened within the detection function. If an "external resource" is opened, it checks whether it is closed according to regulations. If it is not closed according to regulations, the number of resources that the system can open simultaneously will be exhausted, causing the application to freeze or crash. Therefore, an anomaly of "resources not being released" can be determined.

[0134] In another embodiment, a preset detection rule is defined as follows: the function directly uses the received parameter to execute the subsequent process, but does not first check whether the received parameter is empty. However, this will cause the program to immediately encounter an error and stop working. Therefore, it can be determined that there is a "null pointer" exception.

[0135] In another embodiment, a preset detection rule specifically states that the detection function directly modifies the content of the interface in an environment where modification is not allowed. If the content of the interface is directly modified in an environment where modification is not allowed, a crash will occur. Therefore, an anomaly of "state inconsistency" can be determined.

[0136] In another embodiment, a preset detection rule specifically includes: detecting whether a function directly modifies shared data without queuing or locking protection. If a function directly modifies shared data without queuing or locking protection, it may cause the data to be corrupted, or cause the program to detect "other requests interrupting the data modification process" and directly report an error. Therefore, it can be determined that there is a "concurrency conflict" anomaly.

[0137] This embodiment enables the intelligent detection model to detect whether calls between the function to be detected and the target function will cause anomalies in scenarios where the model needs to be detected to input preset detection rules as prompt words. This allows the intelligent detection model to use the preset detection rules as prompt words to detect whether calls between the function to be detected and the target function will cause anomalies.

[0138] This prevents the intelligent detection model from operating freely and confines it to the scope of detection types covered by the preset detection rules. It can specifically identify anomalies of the specific types covered by the preset detection rules, thereby precisely constraining the preset detection model and preventing it from diverging to detect other types of anomalies.

[0139] It can effectively suppress the open-domain illusion of intelligent detection models, balance intelligent generalization ability and engineering determinism, make the preset detection rules traceable, verifiable and iterative, significantly improve the detection accuracy and interpretability of anomalies, reduce unfounded false alarms, and improve credibility and engineering usability.

[0140] In this application, the call chain pattern, function semantic features, parameter constraints and defect criteria to be detected can be clearly defined by preset detection rules, forming a collaborative detection mechanism of "structure-driven + rule-guided + AI-enhanced".

[0141] Secondly, it can not only significantly improve the accuracy, interpretability and engineering controllability of anomaly detection, but also support the continuous evolution and accuracy closure of detection rules oriented towards software quality requirements, overcoming the problems of existing detection such as "over-generalization, serious missed detection, insufficient targeting, insufficient professionalism, blurred boundaries and frequent false alarms".

[0142] This application establishes a high-precision, interpretable, and evolvable code quality assurance mechanism by using functions as the basic detection unit and deeply integrating the function call chain constructed by static analysis with the detection mechanism of the intelligent detection model guided by preset detection rules.

[0143] This application supports explicit definition, version management, and incremental iteration of preset detection rules, forming a closed-loop mechanism of "identifying problems → refining detection rules → verifying and deploying → continuous optimization" to meet engineering quality assurance requirements.

[0144] In the aforementioned embodiments, when there are many preset detection rules, if each preset detection rule is used as a prompt word to detect whether the call between the function to be detected and the target function will cause an exception, the process of each preset detection rule being used as a prompt word to detect whether the call between the function to be detected and the target function will cause an exception will consume time and system resources. Therefore, the total amount of time and system resources consumed overall is very large.

[0145] Secondly, after analyzing a large number of historical testing scenarios, it was found that: To detect whether a call between any two functions will cause an exception, each preset detection rule is used as a prompt word to check if the call between the two functions will result in an exception. However, the results are often the same: most detection rules result in no exceptions, while a small number of rules sometimes cause exceptions. The same applies to detecting whether calls between other two functions will cause exceptions.

[0146] It is evident that when detecting whether a call between two functions will cause an exception, it is often unnecessary to use each preset detection rule as a prompt word to check whether the call between any two functions will cause an exception. Instead, it is possible to use only a small portion of the preset detection rules as prompt words to check whether the call between any two functions will cause an exception, rather than using most of the detection rules as prompt words to check whether the call between any two functions will cause an exception. This can save time and system resources.

[0147] Specifically, each preset detection rule is matched with a trigger condition.

[0148] A trigger condition is used to determine whether a preset detection rule matching the trigger condition should be triggered. If the preset detection rule matching the trigger condition is triggered, then the preset detection rule matching the trigger condition is used as a prompt word. Based on the metadata of the function to be detected, the metadata of the target function, and the call relationship, the function to be detected will be checked to see if the call between the function to be detected and the target function will cause an exception.

[0149] Preset detection rules are specific detection content or specific detection methods.

[0150] This allows for the use of a pre-defined detection rule to check whether calls between functions will cause exceptions when a pre-defined detection rule is needed, thus avoiding unnecessary checks and saving time and system resources.

[0151] Specifically, there are multiple preset detection rules. Each preset detection rule is matched with its own preset trigger conditions.

[0152] When an intelligent detection model uses preset detection rules as prompts and, based on the metadata of the function to be detected, the metadata of the target function, and the call relationship, detects whether calls between the two functions will cause exceptions, the intelligent detection model determines the preset triggering conditions for the calls between the two functions based on the metadata of the function to be detected, the metadata of the target function, and the call relationship. Among multiple preset detection rules, the model selects the preset detection rule that matches the triggered preset triggering condition. Using the determined preset detection rule as a prompt, the model detects whether calls between the two functions will cause exceptions, based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0153] In one embodiment, a preset detection rule is triggered when a function is called by the UI thread (e.g., from Activity.onCreate() or onClick()). Specifically, this preset detection rule checks whether a blocking I / O operation is called within the function. If so, it checks whether the blocking I / O operation is not executed in a background thread. If the blocking I / O operation is not executed in a background thread, it may cause application response errors. Therefore, it can be determined that a "UI thread blocking I / O" exception exists. This preset detection rule has an ID (Identity document) and a name. The ID can be something like RULE_UI_BLOCKING_IO, and the name can be "Disable blocking I / O in the UI thread".

[0154] In another example, a pre-defined detection rule is triggered when a function is called frequently (e.g., a dozen times per second) and crosses modules within the entire codebase. This pre-defined rule specifically checks whether the function has any "external resources" open, such as external files or database query results. If so, it checks whether these resources are properly closed. If not, the system's maximum number of concurrently accessible resources is exhausted, causing the application to freeze or crash. This indicates a "resource not released" exception. This pre-defined detection rule has an ID and a name, such as "resource not released".

[0155] In another example, a pre-defined detection rule is triggered when a function receives a null parameter. Specifically, this rule states that the function directly uses the received parameter to execute subsequent steps without first checking if it's null. However, this causes the program to immediately encounter an error and stop working; therefore, a null pointer exception can be identified. This pre-defined detection rule has an ID and a name, where the name can be "Null Pointer".

[0156] In another example, a pre-defined detection rule is triggered when a function is "delayed in execution (e.g., called only after a network request returns)" but modifies content on the user interface. Specifically, this rule checks whether the function directly modifies content within an environment where UI modification is not allowed. If it does, a crash will occur. Therefore, a "state inconsistency" exception can be identified. This pre-defined detection rule has an ID and a name, where the name could be "state inconsistency".

[0157] In another example, a pre-defined detection rule is triggered when multiple concurrent operations enter the function (e.g., two network requests returning simultaneously, both modifying the same list). This pre-defined rule specifically checks whether the function directly modifies shared data without queuing or locking protection. If so, the data may be corrupted, or the program may detect that another request is interrupting the data modification process and throw an error. Therefore, a "concurrency conflict" exception can be identified. This pre-defined detection rule has an ID and a name, where the name can be "Concurrency Conflict".

[0158] In another embodiment of this application, API calls to middleware or experimental frameworks can also be located in the full code, and it can be detected whether API calls to middleware or experimental frameworks in the full code will cause exceptions.

[0159] For example, check whether the default branch is set properly to prevent all applications from following the experimental branch. If all applications follow the experimental branch, it may cause abnormalities in online functions.

[0160] For example, checking for hard-coding can prevent experiments from being dynamically adjusted, increase release risks, and violate experimental framework design specifications.

[0161] For example, it can detect whether fallback / degradation logic is missing. The lack of a fallback will cause the service to crash or become unusable when the configuration center is unavailable.

[0162] See Figure 5 The diagram illustrates a code detection architecture according to this application. This architecture includes a presentation layer, a call layer, and a model layer.

[0163] The presentation layer includes basic detection information, code information of upstream and downstream functions, and detection conclusion information.

[0164] The basic information for testing includes: the name of the person submitting this testing task, the submission time of this testing task, and the branch of the software code in which the full code to be tested is located (here, the full code can be all the code in a module of the software code, etc.).

[0165] The code information of upstream and downstream functions includes: the source code of upstream and downstream functions and metadata, etc.

[0166] The test results include: the test results obtained after performing this test task.

[0167] Information in the presentation layer can be displayed in the interface, etc.

[0168] The call layer includes a code platform, a network topology platform, and a detection platform.

[0169] The code platform includes a platform for storing code, such as a code repository. The code platform is also used to store information about detection events that trigger detection tasks, as well as information about detection branches.

[0170] The network topology platform supports parsing the entire codebase, including syntax tree parsing, call chain parsing, constructing a topology graph of the call chain, and storing the topology graph of the call chain.

[0171] The detection platform includes various types of detection, such as function slice (function to which the modified code belongs) detection, function-level detection, downstream function call detection, and middleware and experimental framework detection.

[0172] The model layer includes multiple detection models, such as function slice detection model, function-level detection model, downstream function call detection model, and middleware and experimental framework detection model.

[0173] Each detection model can be obtained by inputting prompt words into the general basic model. The prompt words can be the preset detection rules mentioned above.

[0174] See Figure 6 The diagram shows a flowchart of a code detection method according to this application.

[0175] After the scheduled task for code detection is triggered, system resources (such as threads or processes) are requested from the pipeline resource pool of the resource call center. Based on the requested system resources, the code parsing pipeline is triggered, pipeline variables are configured, a detection environment is built, the full code (such as the code of a certain branch) is pulled in the detection environment, the full code is scanned, the call chain of the full code is built, the pre-configured preset detection rules are pulled, and the function calls in the call chain of the full code will cause exceptions based on the preset detection rules. The call chain of the full code and the detection results are stored, and system resources are released.

[0176] See Figure 7 The diagram shows a flowchart of a code detection method according to this application.

[0177] After triggering the code inspection task, in order to balance the depth of review and delivery efficiency, a collaborative execution strategy that combines asynchronous and synchronous inspection can be adopted.

[0178] For synchronous detection, a middleware and experimental framework detection model can be used to detect whether API calls to middleware or experimental frameworks in the full code will cause anomalies.

[0179] For asynchronous detection, the function to which the changed code belongs can be detected based on the function slice detection model, and this function can be used as the function to be detected.

[0180] Based on a function-level detection model, it is possible to detect whether the call of the target function to the function being detected will cause anomalies.

[0181] A downstream function call detection model can be used to detect whether the function to be detected will cause anomalies when calling the target function.

[0182] In asynchronous detection, the process of executing detection based on three detection models is time-consuming and often takes longer than that of synchronous detection. Therefore, the results of synchronous detection can be connected to the Merge Gate, while asynchronous detection can be executed in the background. The detection results of the three detection models are connected to the Merge Gate respectively, ultimately achieving the aggregation of the detection results of synchronous and asynchronous detection.

[0183] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions involved are not necessarily required by this application.

[0184] Corresponding to the embodiments of the methods described above, this application also provides embodiments of the apparatus.

[0185] Reference Figure 8 The diagram shows a structural block diagram of a code detection device according to this application. The device includes: The first determination module 11 is used to determine the function to be detected in the entire code; The second determining module 12 is used to determine, in the full code, a target function that has a calling relationship with the function to be detected, and to determine the calling relationship between the function to be detected and the target function; The detection module 13 is used to detect whether the call between the function to be detected and the target function will cause an exception based on the call relationship.

[0186] In one optional implementation, the second determining module includes: The first acquisition unit is used to acquire the full call relationship between multiple functions in the full code; The first determining unit is used to determine, based on the full call relationship, a target function that has a call relationship with the function to be detected, and to determine the call relationship between the function to be detected and the target function.

[0187] In one optional implementation, the first acquisition unit includes: The acquisition subunit is used to acquire the stored full call relationship, which is generated and stored in advance.

[0188] In one optional implementation, the first determining module includes: The second determining unit is used to determine the changed code in the full code; The third determining unit is used to determine, within the full code, the function to which the modified code belongs; The fourth determining unit is used to determine the function to be detected based on the function to which the changed code belongs.

[0189] In one optional implementation, the second determining unit includes: A determination subunit is configured to, in response to receiving a code change request, determine the code to be changed within the full codebase, the code change request being entered after a change has been made to the full codebase.

[0190] In one optional implementation, the detection module includes: The second acquisition unit is used to acquire the metadata of the function to be detected and the metadata of the target function; The detection unit is used to detect whether the call between the function to be detected and the target function will cause an exception based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0191] In one optional implementation, the detection unit includes: The detection subunit is used to input the metadata of the function to be detected, the metadata of the target function, and the call relationship into the intelligent detection model as input data, so that the intelligent detection model can detect whether the call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0192] In an optional implementation, the detection subunit is specifically used to: obtain preset detection rules; input the metadata of the function to be detected, the metadata of the target function, and the call relationship into the intelligent detection model as input data; and input the preset detection rules as prompt words into the intelligent detection model, so that the intelligent detection model uses the preset detection rules as prompt words to detect whether the call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0193] In one optional implementation, there are multiple preset detection rules; each preset detection rule is matched with its own preset triggering conditions. The detection subunit is specifically used for: the intelligent detection model determining the preset triggering conditions triggered by the call between the function to be detected and the target function based on the metadata of the function to be detected, the metadata of the target function, and the call relationship; obtaining the preset detection rule that matches the triggered preset triggering conditions from multiple preset detection rules; using the determined preset detection rule as a prompt word, and detecting whether the call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

[0194] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0195] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0196] This application also provides a non-volatile readable storage medium storing one or more modules (programs). When these modules are applied to a device, they enable the device to execute the instructions for the method steps in this application.

[0197] This application provides one or more machine-readable media storing instructions that, when executed by one or more processors, cause an electronic device to perform one or more methods as described in the above embodiments. In this application, the electronic device includes a server, a gateway, sub-devices, etc., and the sub-devices are devices such as Internet of Things (IoT) devices.

[0198] Embodiments of this disclosure can be implemented as an apparatus with any suitable hardware, firmware, software, or any combination thereof, configured as desired. This apparatus may include electronic devices such as servers (clusters) and terminal devices such as IoT devices.

[0199] Figure 9 An exemplary apparatus 1300 is schematically shown that can be used to implement the various embodiments of this application.

[0200] In one embodiment, Figure 9 An exemplary device 1300 is shown, which includes one or more processors 1302, a control module (chipset) 1304 coupled to at least one of the processors 1302, a memory 1306 coupled to the control module 1304, a non-volatile memory (NVM) / storage device 1308 coupled to the control module 1304, one or more input / output devices 1310 coupled to the control module 1304, and a network interface 1312 coupled to the control module 1304.

[0201] Processor 1302 may include one or more single-core or multi-core processors, and processor 1302 may include any combination of general-purpose processors or special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, device 1300 can function as a server device such as a gateway in the embodiments of this application.

[0202] In some embodiments, apparatus 1300 may include one or more computer-readable media (e.g., memory 1306 or NVM / storage device 1308) having instructions 1314 and one or more processors 1302 that are combined with the one or more computer-readable media and configured to execute instructions 1314 to implement modules and thus perform the actions in this disclosure.

[0203] In one embodiment, the control module 1304 may include any suitable interface controller to provide any suitable interface to at least one of the processors 1302 and / or any suitable device or component communicating with the control module 1304.

[0204] The control module 1304 may include a memory controller module to provide an interface to the memory 1306. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0205] Memory 1306 may be used, for example, to load and store data and / or instructions 1314 for device 1300. In one embodiment, memory 1306 may include any suitable volatile memory, such as suitable DRAM. In some embodiments, memory 1306 may include double data rate quad synchronous dynamic random access memory (DDR4 SDRAM).

[0206] In one embodiment, the control module 1304 may include one or more input / output controllers to provide an interface to the NVM / storage device 1308 and (one or more) input / output devices 1310.

[0207] For example, NVM / storage device 1308 may be used to store data and / or instructions 1314. NVM / storage device 1308 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable (one or more) non-volatile storage devices (e.g., one or more hard disk drive (HDD), one or more optical disc (CD) drives, and / or one or more digital universal optical disc (DVD) drives).

[0208] NVM / storage device 1308 may include storage resources that are physically part of a device on which device 1300 is mounted, or that can be accessed by the device without being part of the device. For example, NVM / storage device 1308 may be accessed via a network via one or more input / output devices 1310.

[0209] One or more input / output devices 1310 may provide an interface for device 1300 to communicate with any other suitable device. Input / output devices 1310 may include communication components, pinyin components, sensor components, etc. Network interface 1312 may provide an interface for device 1300 to communicate via one or more networks. Device 1300 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, such as accessing wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G, 5G, etc., or combinations thereof.

[0210] In one embodiment, at least one of the processors 1302 may be logically packaged with one or more controllers (e.g., memory controller modules) of the control module 1304. In one embodiment, at least one of the processors 1302 may be logically packaged with one or more controllers of the control module 1304 to form a system-in-package (SiP). In one embodiment, at least one of the processors 1302 may be integrated with the logic of one or more controllers of the control module 1304 on the same die. In one embodiment, at least one of the processors 1302 may be integrated with the logic of one or more controllers of the control module 1304 on the same die to form a system-on-a-chip (SoC).

[0211] In various embodiments, device 1300 may be, but is not limited to, a server, desktop computing device, or mobile computing device (e.g., laptop computing device, handheld computing device, tablet computer, netbook, etc.). In various embodiments, device 1300 may have more or fewer components and / or different architectures. For example, in some embodiments, device 1300 includes one or more cameras, a keyboard, a liquid crystal display (LCD) screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0212] This application provides an electronic device, including: one or more processors; and one or more machine-readable media having instructions stored thereon, which, when executed by the one or more processors, cause the electronic device to perform one or more methods as described in this application.

[0213] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0214] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable information processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable information processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0215] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable information processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0216] These computer program instructions can also be loaded onto a computer or other programmable information processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0217] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the embodiments of the present application.

[0218] Finally, it should 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 terminal device 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 terminal device. 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 terminal device that includes the element.

[0219] The code detection method and apparatus provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and its core ideas. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A code detection method characterized by, The method includes: In the full code, identify the function to be tested; In the full code, a target function with a calling relationship with the function to be detected is identified, and the calling relationship between the function to be detected and the target function is determined; Based on the call relationship, it is determined whether the call between the function to be detected and the target function will cause an exception.

2. The method of claim 1, wherein, In the full code, determining the target function that has a calling relationship with the function to be detected, and determining the calling relationship between the function to be detected and the target function, includes: Obtain the full call relationships between multiple functions in the full code; Based on the full call relationship, a target function with a call relationship to the function to be detected is determined, and the call relationship between the function to be detected and the target function is determined.

3. The method of claim 2, wherein, Obtaining the full call relationships between multiple functions in the full code includes: Retrieve the stored full call relationship, which is generated and stored in advance.

4. The method of claim 1, wherein, The process of identifying the function to be detected within the full code includes: Within the full codebase, identify the changed code; Within the full codebase, determine the function to which the modified code belongs; The function to be detected is determined based on the function to which the modified code belongs.

5. The method of claim 4, wherein, The code identified as changed within the entire codebase includes: In response to receiving a code change request, the code to be changed is determined in the full codebase, the code change request being entered after the full codebase has been changed.

6. The method of claim 1, wherein, The step of detecting whether calls between the function to be detected and the target function will cause exceptions based on the call relationship includes: Obtain the metadata of the function to be detected, and obtain the metadata of the target function; Based on the metadata of the function to be detected, the metadata of the target function, and the calling relationship, it is determined whether the call between the function to be detected and the target function will cause an exception.

7. The method according to claim 6, characterized in that, The method of detecting whether calls between the function to be detected and the target function will cause exceptions based on the metadata of the function to be detected, the metadata of the target function, and the call relationship includes: The metadata of the function to be detected, the metadata of the target function, and the call relationship are all input into the intelligent detection model, so that the intelligent detection model can detect whether the call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

8. The method of claim 7, wherein, The process involves inputting the metadata of the function to be detected, the metadata of the target function, and the call relationship into the intelligent detection model. This allows the intelligent detection model to detect whether calls between the function to be detected and the target function will cause anomalies based on the metadata of the function to be detected, the metadata of the target function, and the call relationship. This includes: Obtain preset detection rules; The metadata of the function to be detected, the metadata of the target function, and the call relationship are all input into the intelligent detection model as input data. The preset detection rules are also input into the intelligent detection model as prompt words, so that the intelligent detection model uses the preset detection rules as prompt words to detect whether the call between the function to be detected and the target function will cause an anomaly based on the metadata of the function to be detected, the metadata of the target function, and the call relationship.

9. The method of claim 8, wherein, There are multiple preset detection rules; each preset detection rule is matched with its own preset triggering conditions. The intelligent detection model uses the preset detection rules as prompts and, based on the metadata of the function to be detected, the metadata of the target function, and the call relationship, detects whether the call between the function to be detected and the target function will cause an anomaly, including: The intelligent detection model determines the preset triggering conditions triggered by the calls between the function to be detected and the target function based on the metadata of the function to be detected, the metadata of the target function, and the call relationship. Among multiple preset detection rules, the preset detection rule that matches the preset triggering condition is selected; Using predetermined detection rules as prompts, and based on the metadata of the function to be detected, the metadata of the target function, and the call relationship, it is determined whether the call between the function to be detected and the target function will cause an exception.

10. A code detection apparatus characterized by comprising: The device includes: The first determination module is used to identify the function to be detected in the entire code. The second determining module is used to determine, within the full code, a target function that has a calling relationship with the function to be detected, and to determine the calling relationship between the function to be detected and the target function; The detection module is used to detect whether the call between the function to be detected and the target function will cause an exception based on the call relationship.

11. An electronic device, comprising: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, A computer program is stored on a computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1 to 9.

13. A computer program product, characterised in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1 to 9.

Images