Error location methods and equipment based on P4 program

Abstract

This disclosure provides a method and apparatus for error localization based on P4 programs. The method includes: receiving a P4 program to be analyzed; converting the P4 program into equivalent Python code; simulating program execution using the Python code to generate an execution trajectory; converting variable assignments, conditional branches, and function calls in the execution trajectory into a static single-assignment SMT formula sequence; calculating the SMT formula sequence using the Craig interpolation algorithm to generate an interpolation sequence based on unsatisfiable constraints; and extracting the minimum set of statements containing the program error from the interpolation sequence using an interpolation reduction algorithm, and mapping it back to the error location in the P4 program to be analyzed.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to error location methods and devices based on the P4 program. Background Technology

[0002] Programmable networking, as a key technology for improving network flexibility, has evolved from Software-Defined Networking (SDN) to a programmable data plane driven by the P4 (Programming Protocol-independent Packet Processors) language. The P4 language enables flexible control of the network device data plane by defining packet parsing, matching tables, and action execution logic, and is widely used in scenarios such as IP forwarding and load balancing.

[0003] Existing error localization techniques are mostly designed for general-purpose programming languages ​​and are difficult to adapt to the characteristics of P4. P4 programs lack runtime status feedback mechanisms; statistical debugging relies on inserting a large amount of predicate statistical behavior data, which is also difficult to deploy in P4 programs constrained by hardware resources. In addition, the root causes of errors in P4 programs often involve complex data flow dependencies, making it difficult to pinpoint them accurately using traditional methods. To address these issues, there is an urgent need for an error diagnosis solution specifically designed for the P4 language. Summary of the Invention

[0004] This disclosure provides a method and device for error location based on the P4 program.

[0005] According to a first aspect of this disclosure, a method for error localization based on P4 programs is provided. The method specifically includes: receiving a P4 program to be analyzed; converting the P4 program into equivalent Python code; simulating program execution using the Python code to generate an execution trajectory; converting variable assignments, conditional branches, and function calls in the execution trajectory into a static single-assignment SMT (Satisfiability Modulo Theories) formula sequence; calculating the SMT formula sequence using an interpolation algorithm to generate an interpolation sequence based on unsatisfiable constraints; extracting the minimum set of statements containing the program error from the interpolation sequence using an interpolation reduction algorithm, and mapping it back to the error location in the P4 program to be analyzed, where the error location includes source code line numbers and / or code segments.

[0006] Based on the above, it can be seen that when locating errors in the P4 program, precise location can be achieved based on function names, line numbers, etc. (rather than simple probability calculations). Furthermore, the use of interpolation reduction algorithms significantly improves the computational efficiency of error location.

[0007] According to a second aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, such that the processor performs the method described in the first aspect of any embodiment of this disclosure.

[0008] According to a third aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect of any embodiment of this disclosure.

[0009] Based on the publicly available solutions described above, this approach constructs a dynamic simulation environment that mirrors the behavior of the P4 program through two conversions (P4 to JSON and then to Python), without relying on hardware devices. When locating errors in the P4 program, precise location can be achieved based on function names, line numbers, etc. (rather than simple probability calculations). Furthermore, the use of interpolation reduction algorithms significantly improves the computational efficiency of error location. Attached Figure Description

[0010] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0011] Figure 1 This is a flowchart illustrating the error location method based on the P4 program provided in an embodiment of this disclosure.

[0012] Figure 2 This is a flowchart illustrating the execution trajectory generation method provided in an embodiment of this disclosure.

[0013] Figure 3 This is a flowchart illustrating the variable definition generation method provided in an embodiment of this disclosure.

[0014] Figure 4 This is a schematic diagram illustrating the code conversion process provided in an embodiment of this disclosure.

[0015] Figure 5 This is a flowchart illustrating the method for generating a directed acyclic graph provided in an embodiment of this disclosure.

[0016] Figure 6 This is a schematic diagram of the P4 program code parsing process provided in an embodiment of this disclosure.

[0017] Figure 7 This is a schematic block diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0018] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0019] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] To facilitate description and make the technical solutions of the specific embodiments of this disclosure easier to understand, the technical terms involved in the specific embodiments of this disclosure are explained as follows before describing the technical solutions of this disclosure.

[0021] Programmable networks are an emerging network architecture that uses programming to control and manage networks, improving their flexibility, customizability, and programmability.

[0022] P4 (Programming Protocol-Independent Packet Processors) is a domain-specific language designed for the network data plane, used to programmatically control the packet processing behavior of network devices such as switches and routers.

[0023] Craig interpolation is a Boolean-based interpolation technique used for automating theorem proving and program analysis. Its basic idea is to decompose a Boolean formula into a logical AND of two Boolean formulas.

[0024] SMT, or Satisfiability Modulo Theories, is a reasoning technique based on the satisfiability problem. Unlike the SAT problem, SMT problems involve not only Boolean formulas but also other types of formulas and notation. In short, SMT problems extend the Satisfiability Problem (SAT) to other theoretical domains, such as arithmetic, arrays, lists, and bit vectors. A key concept in SMT problems is the theory, which is a set of axioms and rules about a particular domain.

[0025] Figure 1 This is a flowchart illustrating the error localization method based on the P4 program provided in an embodiment of this disclosure. Figure 1 The method shown includes steps 101 to 104. This method can be executed by electronic devices such as computers or servers (local servers or cloud servers).

[0026] Specifically, Figure 1 The method shown includes steps 101 to 104.

[0027] In step 101, the P4 program to be analyzed is received, the P4 program is converted into equivalent Python code, and the Python code is used to simulate program execution to generate an execution trajectory.

[0028] When converting the format of the P4 program to be analyzed, firstly, the P4 program is converted into JSON format, and then the JSON format P4 program is converted into Python code. This is because current error checking tools cannot directly locate errors in P4 programs; therefore, error location is performed after format conversion.

[0029] After format conversion, executable Python code is obtained. The Python code is then used to simulate the program execution process, and the execution traces generated during the execution process are saved.

[0030] The execution trajectory mentioned here refers to the dynamic behavior record captured during the execution of the P4 program using Python simulation. Generally, the execution trajectory consists of three parts: preconditions, postconditions, and the logical execution part.

[0031] It should be noted that although the execution trajectory is simulated, the execution logic and results of the trajectory remain consistent with the P4 program being analyzed. Therefore, the execution trajectory accurately reflects the actual execution process and results of the P4 program being analyzed. This conversion does not result in the loss of important information.

[0032] In step 102, the variable assignments, conditional branches, and function calls in the execution trajectory are converted into a static single-assignment SMT formula sequence.

[0033] After obtaining the execution trajectory of the simulated P4 program using the method described above, the variable assignments, conditional branches, and function calls in the execution trajectory are extracted. Furthermore, these elements are converted into an SMT formula sequence using static single assignment form (SSA).

[0034] SMT (Static Assignment Model) formula sequences refer to sequences of logical constraint formulas that convert operations such as variable assignment, conditional branching, and function calls in the program execution trajectory into static assignment (SSA) form. These formulas are based on Satisfiability Modulus (SMT) theory and can describe the state and constraint relationships at each step of the program execution process, used for logical problem solving and error analysis.

[0035] In step 103, the SMT formula sequence is calculated using an interpolation algorithm, and an interpolation sequence is generated based on unsatisfiable constraints.

[0036] After obtaining the SMT formula sequence using the above method, an interpolation algorithm (such as Craig interpolation) can be used to calculate the SMT formula sequence. During the calculation, the SMT formula is broken down into path conditions and error conditions.

[0037] The execution path of a P4 program (e.g., loops, conditional branches) can be transformed into the logical conjunction of an SMT formula (e.g., hdr.times#0 = 5 ∧ hdr.times#1 = 6), and the interpolation algorithm can accurately identify the path constraints that cause conflicts (e.g., the contradiction between hdr.times#0 = 5 and hdr.times#1 == 4).

[0038] The interpolation sequence extracts the minimum set of erroneous statements (e.g., loop logic errors, table entry configuration errors) through interpolation reduction algorithms, which can be directly mapped to the P4 source code location, rather than just providing a probabilistic fault region (because the probabilistic fault region method is inaccurate). Using Craig interpolation for fault location yields more accurate results.

[0039] It's important to note that the Craig interpolation algorithm was chosen here due to its accuracy, efficiency, and suitability for P4 characteristics: it directly locates logical conflicts through the unsatisfiability of the SMT formula, rather than relying on probabilistic information entropy. The interpolation reduction algorithm significantly reduces computational overhead (e.g., merging redundant interpolations reduces the number of verifications). It requires no runtime environment or hardware resource injection, making it suitable for post-compilation verification scenarios in P4 programs. The aforementioned Craig interpolation calculation method effectively solves the problem of logical conflict localization in P4 programs that existing technologies cannot cover.

[0040] In step 104, the minimum set of statements that cause program errors is extracted from the interpolation sequence using an interpolation reduction algorithm and mapped back to the error location in the P4 program to be analyzed.

[0041] After using Craig interpolation to complete the initial error location, the role of the interpolation reduction algorithm is to further filter and refine these interpolations, and finally calculate the so-called error invariants, which are the smallest set of critical statements in the program that can accurately reflect the error.

[0042] As mentioned earlier, the matching tables and actions in the P4 program are converted into functions in Python. This way, knowing only the function name of the erroneous statement in the minimal set of critical statements allows for accurate mapping of the error back to the corresponding function and operation in the P4 program. However, some special cases require special handling. For example, P4 program statements without explicitly defined functions, or statements that cannot be found by function name or line number, require corresponding measures to accurately locate the error.

[0043] Using the aforementioned approach, error localization in the P4 program can be achieved precisely based on function names, line numbers, etc. (rather than simple probability calculations). Furthermore, the interpolation reduction algorithm significantly improves the computational efficiency of error localization.

[0044] like Figure 2 This is a flowchart illustrating the execution trajectory generation method provided in an embodiment of this disclosure. Figure 2 As shown, in one or more embodiments of the present disclosure, receiving the P4 program to be analyzed, converting it into Python code, and using the Python code to simulate program execution to generate an execution trajectory includes the following steps: In step 201, extracting the data packet header vector, metadata, and static data from the P4 program to be analyzed, and converting them into variable definitions represented by Python functions. In step 202, extracting a matching table from the P4 program to be analyzed, and converting the matching fields, matching types, and action parameters of the matching table into a first Python function, wherein the matching fields are used as function parameters, and the action parameters are converted into judgment expressions. In step 203, extracting the next_table field and conditional judgment logic from the P4 program to be analyzed, and constructing the execution logic of a directed acyclic graph simulated by a second Python function. In step 204, based on test data packets or control plane input, using Python code to simulate the execution of variable definitions, the first Python function, and the second Python function to generate an execution trajectory.

[0045] To diagnose and locate errors in the P4 program, the P4 program to be analyzed must first be converted into Python code that can be simulated and executed.

[0046] Specifically, the P4 program to be analyzed first needs to generate a JSON intermediate representation using the p4c compiler. Then, key elements (such as packet header vectors, metadata, static data, and matching tables) are extracted from this JSON file, and finally converted into Python code. It's important to note that the reason for converting the P4 program to Python code is that P4 programs are deployed directly on hardware devices (such as Tofino switches) and lack the runtime debugging environment of traditional programs (such as single-step execution and variable monitoring). By converting the P4 program to Python code, a software simulation environment consistent with hardware behavior can be built, thereby indirectly obtaining dynamic behavior during program execution (such as variable state changes and conditional branch results), providing crucial input data for subsequent error localization.

[0047] The conversion process mainly involves three elements: variable definition, matching table, and dependency relationship. When converting variable definitions, the packet header data and metadata in the P4 program need to be converted into a Python dictionary structure (e.g., hdr['mission5']['times']). Static data (such as registers and counters) are simulated using Python lists (e.g., a_reg=[0]*1). This conversion method preserves the semantic characteristics of the P4 program, such as the handling of the validity bit (POV): the validity bit represented by special characters in the P4 program (e.g., hdr.ethernet.$valid) is simplified to hdr['ethernet']['valid'] in the Python code, eliminating syntactic differences while ensuring consistency in variable naming.

[0048] The transformation of the matching table focuses on the logical abstraction of the match-action table. Specifically, for each P4 program's matching field (e.g., hdr['recirculate']['times']), the function body implements action parameters (e.g., exact match, ternary match, etc.) through if-else branches. For dynamic entries issued by the control plane, the solution further embeds them into the if-else logic of the Python function through a dictionary structure, ensuring full support for dynamic configuration.

[0049] The dependency transformation is based on the control flow analysis of the P4 program. A Directed Acyclic Graph (DAG) is constructed by parsing the `next_table` field and conditional logic, and the nodes (matching table) and edges (jump relationships) of the DAG are mapped to Python function call chains. For example, `recirculate_table()` is triggered when `hdr.recirculate.times>0`, otherwise `tbl_recirculate131()` is executed. This logic is directly reflected through function calls and conditional branches.

[0050] When generating the execution trace, the aforementioned variable definitions, the first Python function, and the second Python function together form the execution foundation of the Python simulator. The simulator starts with the initial assignment of the packet header vector and metadata (e.g., hdr['times'] = 5) and sequentially calls the matching table functions according to the topological order of the directed acyclic graph (DAG). For example, in loop processing logic, the value of hdr['times'] decreases with each function call, and the execution path of each statement is recorded using the globaltrace_lt and localtrace_trace methods of the trace module.

[0051] Specifically, `globaltrace_lt` is responsible for globally tracing the entry function (e.g., `ingress_main()`), while `localtrace_trace` captures variable assignments (e.g., `hdr['times'] = 4`), conditional branch results (e.g., `if hdr['times']>0` is True), and function calls (e.g., `send(port=68)`) line by line, ultimately organizing this information into structured trajectory data. The trajectory data consists of three parts: preconditions (initial variable states), logical execution (dynamic path constraints), and postconditions (assertion verification), and is modeled using a sequence of Static Single Assignment (SSA) formulas. For example, `hdr['times']=5` is transformed into `hdr.times#0=5`, and the conditional branch `if hdr['times']>0` is transformed into `hdr.times#0>0`, which is then transformed into `send.port#0=68`. These formula sequences become the input for subsequent Craig interpolation calculations.

[0052] Based on the aforementioned publicly available solution, this approach constructs a dynamic simulation environment that mirrors the behavior of the P4 program through two conversions (P4 to JSON and then to Python), without relying on hardware devices. The conversion mechanism for variable definitions, matching tables, and dependencies fully preserves the semantics of the P4 program, while the trace module's trajectory capture capability further supports symbolic modeling of path constraints. This provides a foundation for subsequent error localization using Python functions.

[0053] In one or more embodiments of this disclosure, variable definitions include: Python dictionaries and Python lists. For example... Figure 3 This is a flowchart illustrating the variable definition generation method provided in this embodiment. As described in step 201, extracting the data packet header vector, metadata, and static data from the P4 program to be analyzed and converting them into variable definitions in Python function representation includes: In step 201, extracting the data packet header vector, metadata, and static data from the P4 program to be analyzed, wherein the static data includes counter or register values. In step 2012, converting the data packet header vector and the metadata into a Python dictionary supporting nested structures. In step 2013, converting the static data into a Python list.

[0054] In the process of converting a P4 program into Python code, variable definition is fundamental to simulating program behavior. Specifically, the packet header vector and metadata in the P4 program are converted into Python dictionary structures, while static data (such as registers and counters) are simulated using Python lists. This conversion preserves the semantic characteristics of the P4 program while adapting to Python's dynamic execution environment. For example, explicitly declared packet header fields (such as `hdr.ethernet.dst_addr`) and metadata fields (such as `meta.priority`) in the P4 program are represented in Python code as nested dictionaries, i.e., `hdr['ethernet']['dst_addr']` and `meta['priority']`. This structure directly reflects the hierarchical organization of packet header vectors and metadata in P4, while also supporting dynamic assignment and access.

[0055] The transformation of static data is based on its lifecycle characteristics: registers that need to be persisted in P4 (e.g., a_reg) are initialized in Python as a fixed-length list (e.g., a_reg=[0]*1), the length of the list corresponds to the capacity of the register, and the initial value is determined by the definition of the P4 program (e.g., the initial_value_lo field in the JSON intermediate representation). This design allows static data to maintain modification logic consistent with hardware behavior in Python simulation, such as simulating register value updates through index operations (e.g., a_reg[0]=5).

[0056] Based on the publicly available solutions mentioned above, it is known that the behavior of the Python simulator can be made consistent with the actual hardware execution. For example, the header fields simulated by the dictionary support multi-level nested access (e.g., hdr['recirculate']['times']), which is completely consistent with the protocol parsing logic of the P4 program; the registers simulated by the list can realize the limited capacity constraints of hardware resources through index operations (e.g., a_reg[0] represents a single-element register).

[0057] In one or more embodiments of this disclosure, such as Figure 4 This is a schematic diagram of the code conversion process provided in this embodiment of the disclosure. As described in step 202, the matching table extracted from the P4 program to be analyzed is converted into a first Python function, and the extracted matching fields are used as function parameters of the first Python function. The extracted action parameters are converted into judgment expressions in the first Python function. This includes: in step 2021, for table entries declared in the P4 program to be analyzed, the matching fields, matching types, and action parameters are converted into a first Python function, where the matching type includes exact matching or longest prefix matching. In step 2022, if the table entry is issued by the control plane, the table entry is received through a standard interface and converted into a first Python function.

[0058] In the process of converting the matching table in the P4 program into a Python function, it is necessary to distinguish between statically declared table entries and dynamic table entries issued by the control plane to ensure that the simulator can fully cover the program behavior.

[0059] For statically declared table entries, the matching fields, matching algorithms, and action parameters in the P4 program are parsed and mapped to the parameters and logical structure of the first Python function. Specifically, the matching fields of each matching table (e.g., hdr.recirculate.times) are extracted as function parameters of the Python function, the matching algorithms (e.g., exact matching, ternary matching) are converted into corresponding conditional judgment logic (e.g., if times==value: or if (times&mask)==value:), and the action parameters (e.g., send(port=68)) are converted into function call statements embedded in the execution path of the conditional branch. This process is accomplished by analyzing the intermediate representation (JSON format) of the P4 program, for example, extracting the key field, action definitions, and entries of table entries from the JSON file output by the p4c compiler, and finally generating a Python function framework such as def recirculate_table(times, recir_type):...

[0060] The transformation method for dynamic entries issued by the control plane differs from that of static entries. The matching fields and action parameters of dynamic entries need to be obtained through the API interface between the control plane and the data plane, and then integrated into a Python function in the form of a dictionary structure. Specifically, the matching fields (e.g., `dynamic_times`) and action parameters (e.g., `dynamic_action`) of dynamic entries are organized as key-value pairs (e.g., `{"times": 5, "action": "send(port=196)"}`), and extended conditional branching logic is generated by traversing this dictionary structure. For example, based on the if-else framework of static entries, the dictionary structure of dynamic entries is appended as an additional elif branch. This enables the simulation and verification of dynamic configuration. This design retains the deterministic logic of static entries while supporting real-time expansion of dynamic entries, solving the problem of difficulty in simulating dynamic configuration in traditional methods.

[0061] Based on the publicly available solutions described above, a unified function-based transformation of static and dynamic entries achieves full coverage of P4 programs across all scenarios. The transformation of static entries ensures consistency with the syntax structure of P4 programs, while the dictionary-based embedding mechanism of dynamic entries simulates the runtime configuration capabilities of the control plane.

[0062] In one or more embodiments of this disclosure, such as Figure 5This is a flowchart illustrating the method for generating a directed acyclic graph (DAG) provided in this embodiment. As described in step 203, the `next_table` field and conditional logic are extracted from the P4 program to be analyzed, and the execution logic of the DAG simulated by a second Python function is constructed. This includes: in step 2031, parsing the `next_table` field and conditional logic in the P4 program to be analyzed; in step 2032, filling variable definitions into the `next_table` field and conditional logic; and in step 2033, based on the filled `next_table` field, conditional logic, and matching table, constructing the execution logic of the DAG simulated by the second Python function, wherein the nodes of the DAG include the matching table and conditional logic.

[0063] To extract the `next_table` field and conditional logic from the P4 program to be analyzed, and to construct the execution logic of the directed acyclic graph simulated by a second Python function, the control flow structure in the P4 program must first be parsed. The control flow of a P4 program is typically defined by an `apply` block, containing the `next_table` field (used to specify the next matching table to be executed) and conditional logic (such as if-else statements or switch statements). By statically analyzing the abstract syntax tree (AST) of the P4 program, these `next_table` fields and conditional logic are extracted to form a logical representation of the control flow. Next, variable definitions extracted from the P4 program (including packet header vectors, metadata, and static data, converted into Python dictionaries and lists respectively) are populated into these control flow structures. This step ensures that the variable references in the `next_table` field and conditional logic are consistent with the variable definitions in the Python code, thus laying the foundation for subsequent simulated execution. Based on the populated `next_table` field, conditional logic, and matching table, a directed acyclic graph (DAG) is constructed. Nodes include matching tables (corresponding to the `table` definition in the P4 program) and conditional logic (corresponding to branching statements in the control flow). Edges represent control flow transitions (e.g., transitioning from one matching table to the next or a conditional branch). The execution logic of this DAG is simulated using a second Python function. Internally, the function implements node transitions recursively or iteratively, simulating the control flow path of the P4 program when processing data packets.

[0064] The execution logic of the directed acyclic graph (DAG) simulated by the second Python function is combined with the first Python function (derived from the matching table) to generate a complete execution trajectory. The first Python function simulates the execution logic of the matching table in the P4 program, receiving matching fields as parameters and generating corresponding conditional expressions based on action parameters, thus simulating match-action behavior. For example, for a matching table, the first Python function compares the matching fields with the input data packet and executes the corresponding action (such as modifying the data packet header or jumping). The second Python function traverses the nodes of the DAG (matching table and conditional logic), calling the first Python function to process the matching table nodes in the order determined by the topological sort, and determining the jump direction of the control flow based on the conditional logic nodes. During the simulated execution, inputting a test data packet triggers the coordinated execution of the first and second Python functions, recording each variable assignment (such as modification of the data packet header or metadata), conditional branch selection (such as if-else paths), and function call (such as calling action functions), thereby generating an execution trajectory containing variable assignments, conditional branches, and function calls. This trajectory records the execution path of the P4 program under specific inputs in sequence, reflecting the program's dynamic behavior and providing a basis for subsequent error localization.

[0065] Based on the publicly available solutions described above, by abstracting the control flow of the P4 program into a directed acyclic graph (DAG) and combining it with Python code simulation, the accuracy and completeness of the execution trajectory are ensured. The second Python function, simulating the execution logic of the DAG, can accurately capture the control flow jumps of the P4 program. Meanwhile, the first Python function, simulating the execution logic of the matching table, refines the data processing behavior; the two work together to generate a detailed execution trajectory. This method not only preserves the semantic characteristics of the P4 program but also achieves efficient simulation execution through the flexibility of Python code. This solution can systematically record the dynamic execution path of the P4 program, providing accurate input data for subsequent error localization based on SMT formulas and Craig interpolation algorithms, thereby improving the accuracy and efficiency of error localization. Furthermore, the automated modeling of the P4 program's control flow through the DAG solves the problem of not being able to obtain the execution path due to hardware limitations in traditional methods.

[0066] In one or more embodiments of this disclosure, the execution of variable definitions, a first Python function, and a second Python function is simulated using Python code to generate an execution trajectory, including: determining the traversal order of nodes and edges connecting different nodes based on the topological sorting of a directed acyclic graph; inputting variable definitions as function parameters into the first Python function and the second Python function based on test data packets or control plane input; and executing the first Python function and the second Python function after parameter filling based on the traversal order to generate an execution trajectory.

[0067] This paper simulates the process of defining variables and generating execution trajectories using Python code. First, the topological sorting of the directed acyclic graph (DAG) determines the node traversal order. In the control flow of the P4 program, the nodes of the DAG consist of matching tables and conditional logic, with edges representing control flow transitions (such as transitions specified by the `next_table` field). A topological sorting algorithm generates a linearized node access sequence according to the dependencies of the DAG, ensuring that nodes are processed in the correct execution order. For example, matching tables or conditional logic with fewer dependencies are processed first, followed by subsequent nodes. This sorting process is based on the control flow characteristics of the P4 program, ensuring that the simulated execution follows the program's semantic logic. Next, variable definitions (including packet header vectors, metadata, and static data, represented as Python dictionaries and lists respectively) are used as function parameters, combined with test packets or control plane inputs (such as entries issued through a standard interface), and input into the first and second Python functions. The first Python function simulates the execution logic of the matching table in the P4 program. It receives the matching field as a parameter, generates a conditional expression based on the action parameter, and simulates the matching-action behavior (such as modifying or discarding the data packet header). The second Python function simulates the execution logic of the directed acyclic graph. It is responsible for calling the first Python function corresponding to the matching table node in the topological sort order and handling the jump decision of the conditional judgment logic node.

[0068] During the simulation, based on the traversal order determined by topological sorting, the first and second Python functions, after parameter filling, are executed sequentially, generating an execution trajectory that includes variable assignments, conditional branches, and function calls. Specifically, the second Python function traverses each node of the directed acyclic graph. When it encounters a matching table node, it calls the corresponding first Python function, inputs test data packets or control plane data, performs matching operations, and records variable assignments (such as modifying metadata) and action call results. When it encounters a conditional judgment logic node, it evaluates the truth value of the conditional expression based on the input data, selects the appropriate control flow path, and records the branch selection. The execution trajectory records each variable assignment (such as updating data packet header fields), conditional branch selection (such as if-else paths), and function call (such as calling action functions) in sequence, forming a trajectory sequence reflecting the dynamic execution path of the P4 program. To ensure the integrity of the trajectory, the simulation tracks all possible execution paths (e.g., by inputting different test data packets multiple times) and records key state changes in each execution. The entire process leverages the flexibility of Python code to achieve accurate simulation of the semantics of the P4 program, while utilizing the structured representation of a directed acyclic graph to ensure the correctness of the control flow.

[0069] Based on the aforementioned publicly available scheme, the generated execution trajectory can comprehensively capture the dynamic behavior of the P4 program under specific inputs, providing an accurate data foundation for subsequent error localization.

[0070] In one or more embodiments of this disclosure, converting variable assignments, conditional branches, and function calls in the execution trajectory into a sequence of SMT formulas in the form of Static Single Assignment (SSA) includes: capturing erroneous execution trajectories from the execution trajectory based on assertion failures or abnormal termination; decomposing the erroneous execution trajectory to obtain preconditions, logical execution parts, and postconditions; mapping assignment statements in the preconditions to SMT formulas with unique version numbers; mapping assignment statements in the logical execution parts to equality constraints carrying unique version numbers; mapping judgment statements in the logical execution parts to Boolean constraints in the SMT formula sequence; mapping function calls and their parameters in the logical execution parts to logical constraints with unique version numbers; and mapping assignment statements in the postconditions to SMT formulas with output results and unique version numbers.

[0071] To convert the variable assignments, conditional branches, and function calls in the execution trajectory into a Static Single Assignment (SSA) sequence of SMT formulas, it is first necessary to capture the error execution trajectory from the execution trajectory based on assertion failures or abnormal termination. The execution trajectory is generated by Python code simulating the execution of a P4 program and contains a sequence of variable assignments, conditional branches, and function calls. In the simulated execution of the P4 program, assertions (such as user-defined validation conditions) or abnormal termination (such as invalid operations or undefined behavior) will trigger error states. By globally and locally tracing the target function and conditional statements in the execution trajectory, the subsequence containing the error state, i.e., the error execution trajectory, is captured. This trajectory records all variable assignments, branch selections, and function call paths from the program entry point to the occurrence of the error. After capture, the error execution trajectory is decomposed into preconditions, logical execution parts, and postconditions. Preconditions include variable assignments in the initial state of the program (such as the initial field values ​​of the input data packet); the logical execution part covers the dynamic execution path before the error occurs (such as matching table actions and conditional branch selections); and postconditions contain the final variable values ​​of the error state or constraints of assertion failures.

[0072] Next, the decomposed error execution trajectory is mapped to a sequence of SMT formulas in static single-assignment form to ensure that each variable has a unique version number in the execution path. For assignment statements in preconditions (e.g., hdr.ipv4.srcAddr = 192.168.1.1), they are directly mapped to SMT formulas, such as srcAddr_0 = 192.168.1.1, where srcAddr_0 is the initial version number of the variable. In the logic execution part, assignment statements (e.g., hdr.ipv4.ttl = hdr.ipv4.ttl-1) are mapped to equality constraints, such as ttl_n = ttl_(n-1)-1, where ttl_n and ttl_(n-1) represent the current and previous version numbers, respectively, ensuring that each assignment in the static single-assignment form generates a new version. Conditional statements (e.g., `if(hdr.ipv4.ttl>0)`) are mapped to Boolean constraints, such as `ttl_n>0`, and connected to path constraints via logical conjunction to record the conditions for branch selection. Function calls (e.g., the action function `drop()`) and their parameters are mapped to logical constraints, such as representing `drop()` as `is_dropped_n=true`, and assigning unique version numbers to the parameters. Assignment statements in postconditions (e.g., variable values ​​in error states) are mapped to SMT formulas with output results, such as `error_flag_n=true`, reflecting the state of assertion failure or abnormal termination. The entire mapping process is formally represented by a sequence of SMT formulas, preserving the semantics and temporal relationships of the error execution trajectory, providing a foundation for subsequent analysis.

[0073] Based on the aforementioned publicly available scheme, the error execution trajectory is precisely converted into a static single-assignment SMT formula sequence, providing a formalized input for error localization based on the Craig interpolation algorithm. The static single-assignment form eliminates ambiguity in variable reassignment through unique version numbers, ensuring that the formula sequence clearly reflects the program's dynamic behavior. Simplifying the complex P4 program execution trajectory into an analyzable SMT formula sequence not only improves the accuracy of error localization but also provides reliable data support for subsequently extracting the minimum set of error statements using the Craig interpolation algorithm, thereby significantly improving the efficiency of P4 program debugging and verification.

[0074] In one or more embodiments of this disclosure, capturing erroneous execution trajectories from the execution trajectory includes: using a code instrumentation-based tracing module to perform global and local tracing of target functions and target judgment statements in the execution trajectory, wherein global tracing monitors the entire program execution and local tracing targets specific functions or judgment statements; and capturing erroneous execution trajectories based on assertion failure or abnormal termination by analyzing the global and local tracing results.

[0075] The process of capturing erroneous execution traces relies on a code instrumentation-based tracing module to precisely analyze the execution traces generated by the simulated execution of the P4 program. The execution trace records the complete dynamic behavior of the P4 program under specific test data packets or control plane inputs, including variable assignments, conditional branch selections, and function call sequences. The tracing module monitors the program's execution status in real time by inserting probes into the Python code (generated by converting the P4 program format). Global tracing covers the entire program execution path, from the program entry point to the exit point, recording the execution of all matching tables, conditional judgment logic, and action calls, ensuring the capture of the overall behavioral characteristics of the P4 program. Local tracing focuses on specific target functions (such as action functions for matching tables) or target judgment statements (such as if-else branches in the control flow), capturing the local execution details of these key components through fine-grained monitoring. The combination of global and local tracing allows for precise identification of potentially erroneous code segments without losing the overall program context. For example, when a matching table action or conditional judgment causes an exception, local tracing can quickly locate the problem area, while global tracing provides the complete execution context, facilitating analysis of the error's path.

[0076] Capturing error execution paths relies on filtering based on assertion failures or abnormal terminations. Assertion failures are typically triggered by user-defined validation conditions in the P4 program, such as unexpected packet header fields (e.g., `hdr.ipv4.ttl<= 0` should be discarded but is not executed). Abnormal terminations may stem from undefined behavior during program execution, such as accessing invalid metadata fields or missing match tables. The tracing module analyzes global tracing results to identify execution paths containing assertion failures or abnormal terminations, and combines this with local tracing results to extract subsequences from the program entry point to the error occurrence point, forming the error execution path. This path not only includes variable assignments, conditional branches, and function calls that led to the error but also preserves the complete execution path before the error occurred, ensuring accurate backtracking of the error cause in subsequent analysis. Compared to traditional log analysis or manual debugging, this solution significantly improves the efficiency and accuracy of error capture through automated code instrumentation and a two-layer tracing mechanism, while avoiding the risk of missing critical execution details.

[0077] The aforementioned publicly available solution possesses high-precision and systematic error capture capabilities. Global tracing ensures the integrity of the execution trajectory, covering all control flow paths of the P4 program and preventing potential errors from being overlooked due to local analysis; local tracing improves the analysis accuracy of critical code segments, enabling rapid location of problem areas. The capture of error execution trajectories provides precise input for subsequent error localization based on SMT formula sequences and Craig interpolation algorithms, ensuring that the analysis process can focus on the program logic causing the error.

[0078] Based on the publicly available solutions mentioned above, by combining global and local tracing, execution trajectories containing error states can be efficiently captured. This not only improves the accuracy of error localization in P4 programs but also provides a reliable data foundation for formal verification, thereby significantly optimizing the program debugging and verification process.

[0079] In one or more of the schemes disclosed herein, the SMT formula sequence is calculated using the Craig interpolation algorithm to generate an interpolation sequence, including: splitting the unsatisfiable SMT formula sequence into path constraints and error assertions; calculating the interpolation formulas for the path constraints and error assertions based on the Craig interpolation algorithm; extracting the key constraints that lead to unsatisfiability based on the interpolation formulas, wherein the key constraints are used to identify the program statements that cause errors; and constructing the interpolation sequence using the key constraints.

[0080] The process of generating an interpolated sequence by calculating the SMT formula sequence using the Craig interpolation algorithm begins with splitting the unsatisfiable SMT formula sequence into path constraints and error assertions. The SMT formula sequence is derived from the execution trajectory of the P4 program, using a static single assignment (SSA) form, which includes a formal representation of variable assignments, conditional branches, and function calls. Path constraints describe the execution path of the program from the entry point to the error occurrence point, covering variable assignments (e.g., ttl_n = ttl_(n-1) - 1) and Boolean constraints for conditional branches (e.g., ttl_n > 0). Error assertions represent constraints on error states, such as assertion failure (e.g., error_flag_n = true) or abnormal termination conditions. By analyzing the unsatisfiability of the SMT formula sequence (i.e., the conflict between path constraints and error assertions), the formula sequence is divided into two parts: path constraints represent the normal execution logic of the program, and error assertions represent the conditions that lead to errors. This splitting is based on the conflict analysis of the SMT solver, ensuring that the division of path constraints and error assertions accurately reflects the erroneous behavior of the program.

[0081] Based on the Craig interpolation algorithm, interpolation formulas for path constraints and error assertions are calculated. The Craig interpolation algorithm is a formal verification technique used to find an interpolation formula in an unsatisfiable constraint system that contains only common variables of path constraints and error assertions and explains the reason for the unsatisfiability. In the context of a P4 program, the interpolation formula generates a simplified logical expression describing the key conditions leading to the error by analyzing the logical relationship between path constraints (such as variable assignments and branch conditions) and error assertions (such as assertion failures). For example, for an error in a P4 program that causes packet loss, the interpolation formula might be expressed as ttl_n<=0∧is_dropped_n=false, revealing the contradiction that the drop action was not performed when the TTL value is zero. Based on this interpolation formula, key constraints leading to unsatisfiability are further extracted. These constraints directly point to erroneous statements in the program (such as incorrectly implemented actions or conditional judgments). By retaining the core variables and logical relationships related to the error and eliminating irrelevant execution details, key constraints focus on the root cause of the error. Finally, these key constraints are used to construct an interpolation sequence, which is arranged according to the time sequence of the execution path to form an ordered set of constraints, providing a precise analytical basis for subsequent error localization.

[0082] It should be noted that the above-mentioned publicly available solution, which combines the Craig interpolation algorithm with the SMT formula sequence, effectively improves the efficiency and accuracy of error localization. The Craig interpolation algorithm can extract simplified logical constraints from complex SMT formulas, significantly reducing the computational complexity of the analysis while retaining the key information needed for error localization. The SSA form of the SMT formula sequence ensures the uniqueness of variables, avoids ambiguity caused by reassignment, and enables interpolation calculations to accurately track the dynamic behavior of the program. Compared to traditional error localization methods (such as manual debugging or log analysis), this solution systematically analyzes program logic through formal means, quickly pinpointing the statements that cause errors, and is applicable to the complex control flow and matching-action mechanisms of P4 programs.

[0083] In one or more embodiments of this disclosure, extracting the minimum set of erroneous statements from the interpolation sequence using an interpolation reduction algorithm and mapping it back to the error location in the P4 program to be analyzed includes: extracting error invariants from the minimum set of statements leading to the error using a constraint-based simplification interpolation reduction algorithm based on the interpolation sequence, wherein the error invariants are key logical constraints leading to the program error; mapping the error invariants to the source code location in the P4 program to be analyzed based on function names, line numbers, or code segment identifiers. The step of extracting error invariants from the minimum set of statements leading to the error using an interpolation reduction algorithm based on the interpolation sequence includes: merging consecutive identical interpolations and deleting redundant terms; optimizing the interpolation coverage range using binary search to quickly determine key interpolations; and determining the error invariants leading to the error based on the key interpolations; wherein the minimum set of statements consists of multiple error invariants.

[0084] After extracting the minimum set of erroneous statements from the interpolation sequence using an interpolation reduction algorithm, this set is mapped back to its location in the source code of the P4 program being analyzed, enabling precise error localization. The interpolation sequence, generated by the Craig interpolation algorithm, contains a series of key constraints that formally describe the logical conditions that cause the P4 program to be unsatisfiable (i.e., errors occur), such as incorrect execution of match table actions (e.g., packets should have been dropped but were not) or incorrect conditional branch selection (e.g., incorrect next_table jumps). The interpolation reduction algorithm, based on constraint simplification, first preprocesses the interpolation sequence by merging consecutive identical interpolation terms to optimize analysis efficiency. Consecutive identical interpolation terms refer to constraints based on formula equivalence; for example, multiple interpolation formulas all indicating that hdr.ipv4.ttl<=0 leads to an error. These formulas are logically equivalent and can be merged into a single constraint to remove redundant terms and reduce the complexity of subsequent calculations. The merging process ensures that only semantically independent key constraints are retained by comparing the logical expressions and variable references of the interpolation formulas.

[0085] After merging redundant terms, the interpolation reduction algorithm employs a binary search strategy to optimize the interpolation coverage and quickly identify key interpolations directly related to the error. The binary search divides the interpolation sequence into two parts according to the execution path's temporal order, testing each part sequentially to see if it contains the constraints that caused the error. For example, if the interpolation sequence contains 10 interpolation formulas from the program entry point to the error occurrence point, the binary search first tests whether the first 5 formulas are sufficient to reproduce the error. If not, it tests the last 5 formulas or even more subdivided intervals, iterating to narrow the range until the smallest set of key interpolations is located. This process leverages the rapid verification capability of the SMT solver; each test constructs temporary SMT formulas to check the unsatisfiability of constraints, ensuring efficient and accurate selection of key interpolations. Based on these key interpolations, the algorithm extracts error invariants, i.e., the core logical constraints leading to the program error. These error invariants are directly related to specific statements in the P4 program, such as the action definition of the matching table or conditional judgment logic, forming a minimal set of error statements. This minimal set of error statements consists of multiple error invariants, covering all program logic that leads to the error, ensuring comprehensive localization.

[0086] After generating the minimum set of error statements, error invariants need to be mapped back to their locations in the P4 program's source code to provide developers with error information that can be directly referenced. Specifically, the variables and constraints in the error invariants correspond to the variable version numbers (such as ttl_n) in the SMT formula sequence, which is generated from the static single assignment (SSA) form of the execution trajectory. Each variable version number can be traced back to a specific assignment statement, conditional branch, or function call in the P4 program through the context of the execution trajectory. To achieve precise mapping, the system maintains a mapping table from SMT formula variables to P4 source code locations, recording the correspondence between each variable version number and a statement in the P4 program. By statically analyzing the abstract syntax tree (AST) of the P4 program and combining it with the mapping table, the constraints in the error invariants are precisely associated with the function name, line number, or code segment identifier in the source code. For example, if the error invariant involves is_dropped_n, it can be located at the definition line of the drop() action in the matching table. If it involves conditional branch constraints, it can be mapped to the if-else statement in the apply block. The mapping process ensures that each error invariant corresponds to a specific code location in the P4 program, providing developers with clear error location information.

[0087] This solution combines interpolation reduction algorithms with source code mapping to achieve efficient generation of the minimum set of error statements and precise location of errors. Compared to traditional error location methods (such as manual debugging or log analysis), the advantages of the interpolation reduction algorithm lie in its systematic nature and efficiency: merging redundant terms and binary search significantly reduce computational complexity, enabling the algorithm to handle the complex control flow and match-action mechanisms of P4 programs; the extraction of error invariants focuses on the core logic leading to the error, eliminating irrelevant execution details and improving the targeting of the error location.

[0088] Source code mapping leverages the semantic association between SMT formulas and P4 programs. Through variable version numbers and AST analysis, it ensures the accuracy and traceability of error localization results, providing users with intuitive debugging information. This approach, through constraint simplification and precise mapping, not only efficiently generates a minimal set of error statements but also achieves accurate backtracking of P4 program error locations, significantly improving debugging efficiency and error localization accuracy. It provides strong technical support for the verification and optimization of P4 programs.

[0089] To facilitate understanding, the implementation process of the above solution will be explained below through specific embodiments.

[0090] like Figure 6 This is a schematic diagram of the P4 program code parsing process provided in an embodiment of this disclosure. From Figure 6 As can be seen, this public solution is based on the JSON file compiled by p4c under the Tofino architecture and is converted. The conversion process includes three components: data structure parsing and definition, matching table instantiation, and dependency relationship connection conversion.

[0091] First, before simulating the P4 program using the method proposed in this disclosure, all variables appearing in the P4 program need to be defined using Python functions. These variables include packet header vectors and metadata, etc. When defining these variables, a one-to-one correspondence with those in the P4 program is required to facilitate subsequent mapping of found errors back to the P4 program. Subsequently, the tables and actions in the P4 program are abstracted into Python functions. The tables in the P4 program are one of the core abstractions of the language, used to match certain fields of the data packets and perform a series of operations. The tables have only one syntax structure, but the matching types differ; the conversion method is structurally unified as a Python function. In terms of processing logic, appropriate adaptation is required based on the matching type.

[0092] Specifically, each table in the P4 program is converted into a Python function. This Python function receives matching fields as function parameters and calls the corresponding action function to process the data packets. The processing here involves modeling the input data packets as objects, using Python functions to extract matching fields from the data packets, and selecting the action function to be called based on the rule matching results. During the simulation, each processing statement is recorded in the execution trajectory, which is then converted into an SMT formula.

[0093] Similarly, each action in the P4 program is also converted into a Python function, which operates on the data packets according to the rules in the P4 program (that is, defining under what circumstances a certain action is triggered, what processing behavior should be taken after a successful match, which tables are executed in what order, etc.).

[0094] Finally, the dependencies between tables need to be resolved to construct the program's execution logic. Specifically, this involves analyzing the dependencies between each table in the P4 program and converting these dependencies into function calls in Python. This allows the construction of a complete P4 program simulator that can receive data packets as input, process them according to the rules of the P4 program, and return the processing results.

[0095] The following section details the definition of two key data types in Python to better simulate and analyze the behavior of P4 programs. These two data types are: metadata and header data bound to data packets, and static data related to device hardware (such as register data). Before explaining how these data are represented in Python, we will first clarify their meaning and role in P4 programs.

[0096] In the P4 program, packet header data and metadata are key data structures closely associated with data packets. This data is generated when a packet enters the processing pipeline and disappears when the packet leaves. The packet header data and metadata together form the Packet HeaderVector, which is explicitly defined in the P4 program's compiled output JSON file.

[0097] In addition to the explicitly defined packet header and metadata, the P4 program also has an implicit data type: Validity bits (POV). This data is not explicitly defined in the packet header but appears implicitly in the compiled JSON file to indicate whether the packet is valid. When converting this data to Python format, special characters representing validity bits (such as $) are removed to ensure format consistency.

[0098] The static data in a P4 program mainly includes hardware-related data such as counters and registers. This data is initialized when the P4 program is loaded into the device, modified during packet processing, but does not disappear when the packet leaves. The structure of this static data is very similar to lists in Python functions, so Python lists can be used to simulate the static data in a P4 program.

[0099] In P4 programs, the match-action table is a core data structure used to describe how to process input data packets. It typically consists of three parts: match fields, match algorithms, and action set.

[0100] Matching fields refer to attributes of the data packets to be matched, such as source port, destination address, protocol type, etc. Matching algorithms describe the methods for matching these fields, such as exact match, prefix match, range match, etc. Action parameters contain a series of actions; when a match is successful, the packets will be processed according to the rules in the action set.

[0101] To simulate the match-action table more comprehensively in Python code, a Python function (the first Python function mentioned earlier) can be used to represent the match table. The function parameter is the matching field, and multiple if-else expressions are used to execute the corresponding actions. This design allows the Python code to directly reflect the matching rules and action execution logic in the P4 program.

[0102] Specifically, entries already declared in the P4 program can be directly read and converted into Python code. This process typically requires parsing the P4 program's source code to extract relevant matching fields, matching algorithms, and action parameters. With this information, corresponding Python functions can be generated to implement the functionality of the original matching table in the P4 program.

[0103] However, the processing differs slightly for entries issued through the control plane. The control plane, the part of the network device responsible for configuring and managing the data plane, communicates with the data plane through specific API interfaces, issuing configuration information and entries. These interfaces can also be used to retrieve the entries contained in the current tables and then convert them into expressions within Python functions.

[0104] The final step in simulating the P4 program using Python is to assemble the various matching tables into a directed acyclic graph according to a predefined logic, and represent it using Python functions. Therefore, the first step is to examine the conditions in the gateway to determine the first matching table to be executed. Then, the `next_table` field of the current table is used to retrieve the table entries to be executed next.

[0105] In this disclosed scheme, the loop count is decremented by one after each iteration. When the loop count reaches 0, the data packet is sent to the designated server. The goal of this error localization process is to identify the code location that caused the error. Secondly, the JSON file is an intermediate representation of the program compiled from the p4 program. During the conversion process, the p4c compiler effectively preserves the semantic information and control structure of the P4 program by modularizing each control logic unit (such as matching tables and conditional statements) and introducing explicit field mappings (e.g., condition_fields) and control flow jump structures (e.g., next_table_names).

[0106] It should be noted that this JSON file is an intermediate representation of the program compiled by p4c. It transforms the program into a data structure containing a series of expressions, while preserving the program's structure and semantic information. This representation retains the original decision logic and data dependencies of the P4 program, facilitating subsequent behavior reconstruction and error analysis using Python functions and the SMT model.

[0107] The JSON file shows that when the loop count is greater than 0, the `recirculate_table` table will be executed; otherwise, the `tbl_recirculate131` table will be executed. To pinpoint the exact location of the error, the program was converted into equivalent Python code. This equivalent Python code makes it easier to capture the entire program's execution path for error localization.

[0108] This solution will elaborate on the error localization process from three aspects: capturing the error execution trajectory, generating and interpolating the SMT formula, and interpolation reduction algorithm and mapping.

[0109] An error execution trajectory refers to the path where errors occur during program execution, including operations such as function calls, variable assignments, and conditional branches. By collecting error execution trajectories during program execution, the program's execution process can be analyzed to pinpoint the locations that caused program crashes or errors.

[0110] The generation of SMT formulas and Craig interpolation are core steps in error localization using error execution trajectories. An SMT formula is a Boolean formula satisfying a set of constraints, solvable by an SMT solver. In error localization, the SMT formula is generated based on the error execution trajectory during program execution. Specifically, the error execution trajectory is transformed into constraints, which in turn generate the SMT formula. Craig interpolation involves solving the SMT formula to obtain an interpolation sequence. The interpolation sequence is a Boolean sequence satisfying the constraints, used to determine the location of the program error. The interpolation reduction algorithm further processes the interpolation sequence to pinpoint the location of the program error.

[0111] Python provides a `trace` module that can help capture the execution path of a program, thereby enabling program debugging and analysis.

[0112] To obtain the execution trajectory of Python code, you can use the Trace class provided by the trace module. The Trace class provides two methods: globaltrace_lt and localtrace_trace, used for global tracing and local tracing respectively. By overriding these methods, you can obtain the desired execution trajectory results during program execution.

[0113] More specifically, you can inherit the Trace class and override the globaltrace_lt and localtrace_trace methods to obtain the required execution trace results when the program is executed.

[0114] When a program starts running, the interpreter first calls the `globaltrace_lt` method. This method primarily operates at the function or module level entry point, determining whether to trace the function or code block about to be executed. At this stage, the function or conditional statement the program is about to enter can be recorded, providing a foundation for building a complete execution tree later. Through this method, it's possible to identify which logical code blocks, functions, or control branches the program has entered during execution; therefore, it primarily undertakes global control of the program's execution path.

[0115] Once the program actually enters a function or block of logic, the `localtrace_trace` method will be continuously called. This method offers more detailed processing; it's triggered every time a line of code is executed, providing the context of that line, including information about the current frame, line number, and variable values. Therefore, the execution of each statement can be captured within this method, such as variable assignments, conditional statements, loop iterations, and function calls and returns. By tracing the results using this method, not only can the program's execution flowchart be reconstructed, but the specific relationships between control and data dependencies can be further understood, providing detailed evidence for debugging and error analysis.

[0116] By combining these two tracing methods of the Trace class, not only can the overall execution structure of the program be obtained, but also the semantic behavior of each step can be deeply understood. In the public solution, this tracing mechanism is used as a tool to record the execution path of the Python simulation program after equivalent transformation. The program execution trajectory obtained by tracing is used as input to provide subsequent symbolic execution and SMT (Satisfiability Modulo Theories) formula modules.

[0117] After obtaining the execution trajectory in the above way, the execution trajectory can be divided into three parts: preconditions, logical execution part, and postconditions.

[0118] First, there are the preconditions, which are the conditions that must be met before the program can execute. In the simulated Python function, preconditions are typically the process of assigning values ​​to the packet header. When a packet arrives at the switch, the switch needs to parse it and generate the corresponding packet header structure. This process can be described using the SMT formula. Preconditions are fundamental to program execution; if these conditions are not met, the program may not be able to produce the required error execution trajectory, therefore, they need to be verified and tested.

[0119] Secondly, the logic execution section shows which statements the program executes given that the preconditions are met. This section is the core of the program and is crucial for its correctness. By analyzing the execution path of this section, potential problems and errors can be identified, allowing for appropriate debugging and repair.

[0120] Finally, there are the postconditions, also known as assertions. Postconditions determine whether the program executes correctly by checking if the given conditions are met. In simulated Python programs, postconditions are typically determined by checking the program's output. If the output matches the expected result, the program executes correctly; otherwise, there is a problem.

[0121] Static Single Assignment (SSA) is an intermediate representation used for compiler optimization and program analysis. In SSA, each variable is assigned a value only once, and each variable definition has a unique version number. This special form helps compilers and program analyzers better understand the semantics of the program, enabling more precise optimization and analysis.

[0122] In traditional program representations, a variable may be assigned a value multiple times, resulting in different values ​​for the variable in different code paths. This poses a significant challenge to program analysis and optimization, as the compiler or analyzer needs to track all possible paths of the variable's value. However, in SSA (Self-Assigned Variable) programming, a variable is only assigned a value once, creating a new version of the variable with each assignment. These different versions of the variable are independent of each other, allowing the compiler or analyzer to more easily track the flow of variable values, thus enabling more precise optimization and analysis.

[0123] The process of converting the execution trajectory into a static single-assignment SMT formula is as follows.

[0124] The preconditions define initial values ​​for header data, metadata, and static data. These initial values ​​typically appear in the form of assignment statements. Since these assignments themselves represent the starting variable states of program execution, they can be treated as the zeroth assignment of each variable, following the concept of Static Single Assignment (SSA), and each initial assignment can be assigned a unique version number. In this way, the assignment statements of the preconditions can be directly mapped to the corresponding equation constraints in the SMT formulas. Here, "direct mapping" refers to obtaining the corresponding logical constraints solely through syntactic mapping, without requiring complex reasoning or path analysis of the program behavior. Each assignment statement is considered an equation constraint; the version number suffix to the variable name indicates the order and uniqueness of the assignments. Multiple assignment statements are connected through logical conjunction to form complete precondition constraints.

[0125] The logic execution section. This section needs to consider several cases. The first is the assignment statement. Ordinary assignment statements are also mapped to equality constraints in SMT based on the SSA concept, representing the updating of variable values ​​and the incrementing of versions.

[0126] The second type is conditional statements. In this case, the results of the conditional statements need to be constrained. These constraints limit the range of values ​​for conditional variables in the execution path to ensure that the model reflects the reality of the path conditions. For example, the if statement `if hdr['recirculate']['valid'] == 1` will be converted to `('hdr.recirculate.valid#0' = 1)` to constrain the variable. Conditional statements typically involve equality, inequality, or logical combinations, such as `a > b`, `x != 0`, etc., which are all converted into corresponding SMT logical expressions according to specified conversion rules. These expressions form path constraints in the form of logical conjunctions, ensuring that the SMT model accurately expresses the branching behavior of the program.

[0127] The third scenario is function calls, which can be further divided into two types: parameterless calls, which can be ignored (e.g., `ingress_main()`), and parameterized calls. When a function call with parameters occurs in the program, the parameters are actually the initial assignments of variables within the function, and these assignments affect the state of the function during execution. Therefore, when converting the program execution trajectory into an SMT formula, the assignment relationships of these parameters must be accurately expressed in the form of logical constraints. Specifically, each function parameter is treated as a variable, and its value is explicitly assigned a specific actual parameter value during the call. During the conversion, a version number (following the SSA format) is appended to the function parameter variable to indicate the unique assignment of that parameter in that call. Note that the function name should be added before the variable to prevent naming conflicts. `return / pass` statements do not need to be converted into SMT formulas.

[0128] The postconditions are the same as the preconditions, so you can directly convert them into SMT formulas.

[0129] First, the definition of interpolation needs to be clarified. In the public scheme, interpolation refers to the state at a specific position. It can be seen as an abstract representation of the program state after all the code before that position has been executed.

[0130] This representation is similar to the watch window in the integrated development environment (IDE) of a traditional programming language, allowing observation of key properties during program execution. Therefore, interpolation serves both as a summary and generalization of the results of previous code execution and as an initial constraint on the execution of subsequent code.

[0131] The key to the application of Craig interpolation in error localization lies in its ability to extract the "critical intermediate state" or "critical constraint" that leads to the error based on the logical constraints generated during program execution (usually expressed in the form of SMT formulas), thereby helping to accurately locate the root cause of the error in the program.

[0132] Specifically, in the analysis of the execution path, each operation, conditional judgment, and variable assignment along the path is transformed into a corresponding SMT formula. These formulas describe the constraints that allow the program to reach a certain state from its initial state. When an error occurs in the program, such as an assertion failure or a postcondition not being met, the corresponding SMT formula will become unsatisfiable. This unsatisfiability means that there is a logical conflict between the path conditions and the error conditions.

[0133] Craig interpolation breaks down an overall unsatisfiable SMT formula into two subsets: one representing the first half of program execution (e.g., path condition A) and the other representing the second half (e.g., error condition B). The Craig interpolation algorithm calculates an interpolation formula that includes only variables common to A and B, but precisely expresses the reason for the incompatibility between A and B. In other words, the interpolation formula summarizes the "critical intermediate states" or "critical constraints" that lead to the conflict, reflecting the conditions satisfied at a certain point in program execution that contradict the error conditions.

[0134] In the actual error localization process, the program's execution trajectory is first transformed into a series of SMT formulas, and then divided into several sub-formulas according to the execution steps. For these unsatisfiable sub-formula pairs, Craig interpolation is used to calculate the corresponding interpolation formulas. Each interpolation formula represents the state abstraction when the program executes to a certain critical node. By analyzing these interpolation formulas, the scope of the error can be gradually narrowed down, and the specific code segment and variable assignment that caused the conflict can be located.

[0135] Therefore, the core of Craig interpolation lies in breaking down and interpolating different SMT formulas to extract key constraints that reflect the root causes of errors. This method can not only verify whether there are errors in the program, but also accurately pinpoint the location and specific conditions of the errors, greatly improving the efficiency and accuracy of error localization.

[0136] After using Craig interpolation to complete the initial error localization, the role of the interpolation reduction algorithm is to further filter and refine these interpolations, and finally calculate the error invariant, which is the set of the smallest critical statements in the Python program that can accurately reflect the error.

[0137] The following specific example illustrates this process: Assume there is an error execution trajectory, corresponding to a series of SMT formulas. These SMT formulas describe the key intermediate states and key constraints at each step of the program. Through Craig interpolation, a series of interpolation expressions are obtained, each corresponding to an abstract state after the execution of a certain section of code in the program.

[0138] These interpolations are essentially summaries of the execution results of code snippets, covering the relationship between that code snippet and subsequent program states.

[0139] Next, the interpolation reduction algorithm processes this interpolation sequence. Since consecutive identical interpolations mean that the corresponding program segments have equivalent effects on the error state, these program segments can be regarded as members of the same "error invariant" group. Therefore, the interpolation reduction algorithm traverses the interpolation sequence, looking for consecutive and identical interpolation expressions, and merges them into a key interpolation to avoid duplicate calculations.

[0140] Then, the interpolation reduction algorithm analyzes the relationship between these key interpolations and their corresponding program segments to determine which specific statements belong to the set of error invariants. In other words, it filters out those statements that are indispensable within the interpolation coverage area; these statements are the root causes of the errors. Put simply, the reduction process focuses on minimizing and representing the error invariants by eliminating statements that are irrelevant to or repetitive with the errors.

[0141] There are many algorithms for interpolation sequence reduction. One is the basic algorithm, which directly substitutes each interpolation value into each statement to calculate whether the interpolation value can cover the statement, and finally obtains the coverage range corresponding to each interpolation value, thus finding the corresponding error invariant. The second method utilizes binary search. If interpolation value I can be used as an interpolation value at both statement i and statement j, then usually all interpolations from statement i to statement j are replaced with I. In this way, finding the coverage of interpolation value I does not require trying each one individually; a binary search can be used directly.

[0142] Based on the nature of the P4 program, which limits the number of times the same variable can be processed in a single operation, there is a high probability that the interpolation values ​​corresponding to adjacent statement positions will be the same. We can directly compare whether they are equal without having to perform reduction by searching and verifying, thus saving a lot of time spent calling the interpolation theorem to prove it.

[0143] This disclosed solution employs an improved interpolation reduction algorithm based on the first fundamental algorithm. Its core lies in taking the SMT formula sequence corresponding to the erroneous execution trajectory as input, calculating and processing the interpolation sequence, and ultimately locating the critical execution trajectory related to the error. Specifically, it first requires obtaining an interpolation sequence calculation function. This function is typically implemented based on existing interpolation theorems and theorem provers. The input is a set of unsatisfied SMT formula sequences, and the output is a set of interpolation formulas. These interpolation formulas reflect the transitional properties between different states during program execution in sequence form. Using this function, the input SMT formula sequence can be progressively divided into multiple incompatible sub-formula pairs, and the interpolation between each pair of sub-formulas can be calculated, thus obtaining the complete interpolation sequence.

[0144] When obtaining interpolation sequences, different types of SMT formulas will affect the computational complexity and the specific form of the interpolation. For example, interpolation calculations are relatively straightforward for linear arithmetic or Boolean formulas, while when complex data structures such as arrays and bit vectors are involved, interpolation generation may require more complex reduction and abstraction methods.

[0145] To reduce subsequent computational load, the algorithm iterates through the obtained interpolation sequence and determines whether adjacent interpolations are duplicates. The criterion is the logical equivalence of the interpolation formulas or the consistency of their symbolic representations. When two consecutive interpolation expressions are identical, it indicates that the corresponding program state abstraction has not changed, and this part of the interpolation can be considered redundant. Therefore, deleting duplicate interpolations effectively shortens the interpolation sequence. This method analyzes the correspondence between the interpolation sequence and the original program statements, and uses strategies such as binary search to efficiently determine the minimum set of interpolations that covers all erroneous behaviors, thereby extracting key error invariants.

[0146] The implementation flow of the first interpolation reduction algorithm is as follows: The input is a sequence of SMT formulas (statements), representing the logical formulas generated statement by statement in a certain error execution path. The output is a list of error location results (error_traces), which contains the positions of statements considered directly related to program errors and their interpolation expressions.

[0147] The first step is to call the interpolation function `sequence_interpolant(statements)` to perform interpolation calculations on the entire SMT formula sequence, generating the corresponding interpolation sequence `interpolants`. Each interpolation represents an abstraction of the state before a certain position in the program execution path.

[0148] Next, the algorithm initializes an empty list `key_interpolants` to store meaningful subsets of interpolations. Then, starting with the first interpolation in the interpolation sequence, it iterates through the entire sequence. For each interpolation `itpl`, it is compared with the previous interpolation `prev_itpl`. If they are not equal, the current interpolation is added to `key_interpolants`, indicating that it represents an actual change in the program state. Regardless of whether it is added, the current interpolation is updated to `prev_itpl` for the next round of comparison.

[0149] After the traversal is complete, to ensure that the last interpolation in the interpolation sequence is not missed, the algorithm adds the last interpolation back to key_interpolants.

[0150] Finally, the algorithm calls the `computing_abstract_error_traces(key_interpolants)` function to further analyze the reduced interpolation sequence, extract the abstract execution trajectories related to the error behavior, and return them as the final result.

[0151] As mentioned earlier, by converting the matching table and actions in the P4 program into functions in Python, we only need to know the name of the function where the error execution trajectory is located to accurately map the error back to the corresponding function and operation in the P4 program.

[0152] In addition, some special cases require special handling. Specifically: ordinary matching tables and actions can be mapped back to P4 programs through function names. As the basic elements of P4 programs, matching tables and actions are translated into Python functions during the conversion process. Therefore, function names can act as a bridge between P4 programs and Python programs, realizing the mapping from Python program error statements to P4 programs.

[0153] P4 program statements not placed in explicit functions are translated into match lists and actions with line numbers, which can be mapped back to P4 programs. This is because the compiler automatically generates anonymous match lists and actions for these isolated P4 statements and adds line numbers to the end of their names to distinguish them from other match lists and actions. Therefore, line numbers can also be used to map Python error statements to P4 programs.

[0154] For the remaining cases, if the statement in the P4 program cannot be directly located by function name or line number, regular expression matching is needed to assist in mapping errors in the P4 program. For example, the error message "Failure ingateway control block: header parsing failed" points to the control flow module gateway, but there is no specific statement. The control block name can be matched using the regular expression "control\s+gateway\s*\(", to find code like "control gateway(inout headers hdr, inout metadata meta, ...)", and further analysis can be performed to see if there are any erroneous related statements inside the control block.

[0155] The execution subject of the error location method based on the P4 program in the specific embodiments of this disclosure can be an electronic device such as a server (including a local server or a cloud server).

[0156] Therefore, based on any of the above embodiments, this disclosure also provides an electronic device that can execute the error location method based on the P4 program of any of the embodiments described above.

[0157] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0158] Figure 7 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure.

[0159] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0160] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one connection line is used in this diagram, but this does not imply that there is only one bus or only one type of bus.

[0161] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0162] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0163] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0164] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0165] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0166] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0167] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A method for error localization based on P4 programs, characterized in that, The method includes: The system receives a P4 program to be analyzed, converts the P4 program into equivalent Python code, and uses the Python code to simulate program execution, generating an execution trajectory. Specifically, this includes: extracting data packet header vectors, metadata, and static data from the P4 program to be analyzed, and converting them into variable definitions represented by Python functions; extracting a matching table from the P4 program to be analyzed, and converting the matching fields, matching types, and action parameters of the matching table into a first Python function, where the matching fields serve as function parameters and the action parameters are converted into conditional expressions; extracting the next_table field and conditional judgment logic from the P4 program to be analyzed, and constructing the execution logic of a directed acyclic graph simulated by a second Python function; and, based on test data packets or control plane input, using the Python code to simulate the execution of the variable definitions, the first Python function, and the second Python function, generating an execution trajectory. Convert the variable assignments, conditional branches, and function calls in the execution trajectory into a static single-assignment SMT formula sequence; The SMT formula sequence is calculated using an interpolation algorithm, and an interpolation sequence is generated based on unsatisfiable key constraints; wherein the key constraints are used to identify program statements that cause errors. The process of extracting the minimum set of statements leading to program errors from the interpolation sequence using an interpolation reduction algorithm and mapping it back to the error location in the P4 program to be analyzed specifically includes: extracting error invariants from the minimum set of statements leading to errors using a constraint-simplification-based interpolation reduction algorithm based on the interpolation sequence, wherein the error invariants are key logical constraints leading to program errors; wherein, the extraction of error invariants from the minimum set of statements leading to errors using the interpolation reduction algorithm based on the interpolation sequence includes: merging consecutive identical interpolations in the interpolation sequence based on formula equivalence and deleting redundant terms; optimizing the program path covered by interpolation through binary search to determine key interpolations; determining the error invariants leading to errors based on the key interpolations, wherein the minimum set of statements consists of multiple error invariants; and mapping the error invariants to the source code location in the P4 program to be analyzed based on function names, line numbers, or code segment identifiers.

2. The error location method based on the P4 program according to claim 1, characterized in that, The variable definitions include Python dictionaries and Python lists; the variable definitions extracted from the P4 program to be analyzed, including the data packet header vector, metadata, and static data, and converted into Python function representations, include: Extract the packet header vector, metadata, and static data from the P4 program to be analyzed, wherein the static data includes counter or register values; Convert the packet header vector and the metadata into a Python dictionary that supports nested structures; Convert the static data into a Python list.

3. The error location method based on the P4 program according to claim 1, characterized in that, The process involves extracting a matching table from the P4 program to be analyzed, and converting the matching fields, matching types, and action parameters of the matching table into a first Python function. The matching fields serve as function parameters, and the action parameters are converted into conditional expressions, including: For the table entries declared in the P4 program to be analyzed, the matching field, matching type and action parameter are converted into the first Python function, wherein the matching type includes exact match or longest prefix match; If the entry is issued by the control plane, it is received through a standard interface and converted into the first Python function.

4. The error location method based on the P4 program according to claim 1, characterized in that, The step of extracting the next_table field and conditional judgment logic from the P4 program to be analyzed, and constructing the execution logic of the directed acyclic graph simulated by the second Python function, includes: Analyze the next_table field and condition judgment logic in the P4 program to be analyzed; The variable definitions are then populated into the next_table field and the conditional judgment logic; Based on the populated next_table field, condition judgment logic, and matching table, execution logic of a directed acyclic graph simulated by a second Python function is constructed, wherein the nodes of the directed acyclic graph include the matching table and condition judgment logic.

5. The error location method based on the P4 program according to claim 1, characterized in that, The execution trajectory is generated by simulating the execution of the variable definition, the first Python function, and the second Python function using Python code, including: Based on the topological sorting of the directed acyclic graph, the traversal order of nodes and edges connecting different nodes is determined. The variable definition is passed as a function parameter, based on the test data packet or control plane input, and input to the first Python function and the second Python function; Based on the traversal order, the first Python function and the second Python function with filled parameters are executed to generate the execution trajectory.

6. The error location method based on the P4 program according to claim 1, characterized in that, Convert the variable assignments, conditional branches, and function calls in the execution trajectory into a static single-assignment SMT formula sequence, including: Based on assertion failure or abnormal termination, an erroneous execution trajectory is captured from the execution trajectory; wherein, capturing the erroneous execution trajectory from the execution trajectory includes: using a code instrumentation-based tracing module to perform global and local tracing on the target function and target conditional statement in the execution trajectory, wherein global tracing monitors the entire program execution, and local tracing targets specific functions or conditional statements; and capturing the erroneous execution trajectory based on assertion failure or abnormal termination by analyzing the global and local tracing results. The erroneous execution trajectory is decomposed to obtain the preconditions, the logical execution part, and the postconditions; Map the assignment statements in the preconditions to SMT formulas with unique version numbers; Map the assignment statements in the logic execution section to equality constraints carrying unique version numbers; Map the judgment statements in the logic execution section to Boolean constraints in the SMT formula sequence; Map the function calls and their parameters in the logic execution section to logical constraints with unique version numbers; The assignment statements in the postconditions are mapped to SMT formulas with output results and unique version numbers.

7. The error location method based on P4 program according to claim 1, characterized in that, The calculation of the SMT formula sequence using an interpolation algorithm, generating an interpolation sequence based on unsatisfiable key constraints, includes: The unsatisfiable SMT formula sequence is broken down into path constraints and error assertions; The interpolation formulas for the path constraints and error assertions are calculated based on the Craig interpolation algorithm; Based on the interpolation formula, key constraints that lead to unsatisfaction are extracted, wherein the key constraints are used to identify program statements that cause errors. The interpolation sequence is constructed using the key constraints.

8. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the method of any one of claims 1 to 7.

Images