A data access conflict defect detection method, system and application based on a large language model

Abstract

This invention discloses a data access conflict defect detection method based on a large language model, comprising the following steps: analyzing the code under test using static analysis tools to identify shared variables and their read / write information; extracting function slices containing read / write operations of shared variables from the code; performing data access conflict detection on the function slices using a large language model that has been enhanced and fine-tuned through retrieval, and outputting the detection results. This invention also discloses a detection system implementing the above detection method, which has a wide range of application scenarios. This invention can effectively support data access conflict defect detection in highly complex software, helping to improve the accuracy of data access conflict defect detection and providing important support for the development and maintenance of high-quality concurrent software.

Description

Technical Field

[0001] This invention belongs to the field of software code analysis technology, and relates to a method, system and application for detecting data access conflict defects based on a large language model. Background Technology

[0002] Real-time embedded systems are computer systems that respond to input and complete tasks within strict time constraints. They are widely used in industrial automation, automotive electronics, medical devices, aerospace, and consumer electronics. Real-time embedded systems improve efficiency and response speed by executing multiple tasks in parallel. However, without proper timing control, multiple tasks executed in parallel are prone to data access conflicts, leading to data inconsistencies, program crashes, or other unpredictable and destructive behaviors, threatening software reliability and performance.

[0003] Data access conflict detection is a key technology for ensuring the correctness and performance of real-time embedded system software. Traditional data access conflict detection methods mainly rely on rule-based static analysis tools, which check for potential problems in the code through predefined rule sets. Although these tools are effective in some cases, they are often unsuitable for highly complex real-time embedded system software and suffer from high false positive and false negative rates. This results in many potential conflicts not being detected in a timely manner, thus affecting the stability and performance of the system. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the present invention aims to provide a data access conflict defect detection method based on a large language model. This method, based on traditional static analysis techniques to extract shared variables and their read / write information, combines access conflict atomicity violation rules and call graph constructor slicing. It then utilizes a retrieved and fine-tuned large language model to automatically detect data access conflicts in the tested real-time embedded system code. Compared to traditional data access conflict detection methods that rely on completely static analysis, this invention is not only applicable to highly complex real-time embedded system software but also helps improve the accuracy of data access conflict detection, providing strong technical support for the development of high-quality real-time embedded system software.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A data access conflict defect detection method based on a large language model includes the following steps:

[0007] Step 1: Use static analysis tools to analyze the code under test and identify the shared variables and their read / write information in the code under test;

[0008] Step 2: Extract function slices containing shared variable read / write operations from the code under test;

[0009] Step 3: Input the data access conflict detection prompt engineering template and function slices into the large language model after retrieval enhancement and fine-tuning, perform data access conflict detection, and output the detection results.

[0010] Furthermore, in step one, the static analysis tool analyzes the program's source code to identify information such as variables, function calls, data flow, and control flow.

[0011] The shared variable refers to a variable that different execution units access simultaneously in a concurrent execution environment, used to pass information or status between different tasks; in specific implementation, the shared variable may include global variables, static variables, or variables shared through certain synchronization mechanisms (such as locks);

[0012] The read / write information includes the type of operation performed by each execution unit on the shared variable.

[0013] Furthermore, step two specifically includes the following steps:

[0014] Step 2.1: Based on the known entry points of the main function and the interrupt function, filter and summarize the initial shared variable set IG that is read and written in the main function and the interrupt function;

[0015] Step 2.2: Based on the atomicity violation rules for data access conflicts, filter the set of shared variables GV in IG that are most likely to have atomicity violation defects; the atomicity violation rules include data race defects such as read-write-read (RWR), write-write-read (WWR), read-write-write (RWW), and write-read-write (WRW);

[0016] Step 2.3: Analyze the function call relationship based on the call graph of the code under test, and extract the function entry point of each shared variable in GV and the function slice in its call chain.

[0017] Furthermore, step 2.2 specifically includes the following steps:

[0018] Step 2.2.1: Determine whether the IG has been traversed. If so, end the shared variable filtering; otherwise, select a shared variable sv from the IG in order and continue to step 2.2.2.

[0019] Step 2.2.2: Determine whether the interrupt function of sv contains at least one read or write operation of the shared variable. If yes, continue to step 2.2.3; otherwise, return to step 2.2.1.

[0020] Step 2.2.3: Determine whether the main function of sv contains at least one read or write operation on the shared variable. If yes, continue to step 2.2.4; otherwise, return to step 2.2.1.

[0021] Step 2.2.4: Determine whether the operations of sv in all interrupt functions and the main function are not limited to read or write operations. If yes, continue to step 2.2.5; otherwise, return to step 2.2.1.

[0022] Step 2.2.5: Determine if the total number of operations of sv in all interrupt functions and the main function is at least three. If yes, continue to step 2.2.6; otherwise, return to step 2.2.1.

[0023] Step 2.2.6: When sv only involves read operations in the interrupt function, determine whether there are at least two write operations on the shared variable in the main function. If so, add sv to GV; otherwise, return to step 2.2.1.

[0024] Furthermore, the implementation of step 2.3 includes:

[0025] By constructing a call graph of the code under test using static analysis tools, the entry point of each shared variable in the shared variable set GV is identified in the relevant function, and the position where the function starts to execute is determined. Through call graph analysis, starting from the entry point of the shared variable, the call chain is traversed upwards and downwards to extract all functions and their code fragments related to the shared variable, forming a function slice.

[0026] The function slices provide the usage context of shared variables at different call levels, facilitating a comprehensive understanding of their read / write operations and potential data access conflicts. Furthermore, analyzing the slices helps pinpoint potential atomicity violations, improving the accuracy and efficiency of defect detection. The obtained function slices are stored in a structured format for easy subsequent retrieval and dynamic updates.

[0027] Furthermore, step three specifically includes the following:

[0028] Define a data conflict detection prompt template, which includes four parts: analysis objective, atomicity violation problem domain, task execution steps, and structured output;

[0029] And / or,

[0030] Build a knowledge base of data access conflict defect cases;

[0031] And / or,

[0032] The data access conflict detection prompts the engineering template and GV-related function slices, which are then input into the fine-tuned large language model to implement data access conflict detection based on retrieval enhancement.

[0033] Furthermore, constructing a knowledge base for data access conflict defect cases specifically includes the following steps:

[0034] Step 1: Input the code snippets of the data access conflict atomicity violation defect dataset into the general large language model, extract information such as code function, defect pattern, defect triggering code snippet, defect triggering conditions and detailed description, and establish a data access conflict defect case knowledge base;

[0035] Step II: Divide the knowledge base content by setting text box size, text block overlap processing and word segmentation strategy, and establish a knowledge base index for data access conflict defect cases;

[0036] Step III: Convert the indexed data access conflict defect knowledge case database into vector form to build a data access conflict defect vector database, supporting efficient similarity retrieval.

[0037] Furthermore, step III specifically includes the following steps:

[0038] Step 3.3.1: Convert the query content in the prompt information generated based on the data access conflict detection prompt project template and GV related function slices into vector form;

[0039] Step 3.3.2: Perform vector similarity retrieval from multiple dimensions, including code function, defect-triggered code snippets, and defect-triggered conditions;

[0040] Step 3.3.3: Sort the vector similarity retrieval results, and output the top-ranked retrieval results as the final data access conflict detection results using a large language model.

[0041] The present invention also proposes a detection system for implementing the above detection method. The monitoring system includes: a data access conflict detection template construction module, a data access conflict defect knowledge base construction module, a text block segmentation and word segmentation module, a defect case knowledge base indexing module, a vectorization and retrieval module, a data access conflict detection module, and a conflict detection result sorting and reasoning module.

[0042] The data access conflict detection template construction module defines the detection framework and rules, and constructs the basic engineering template for data access conflict detection.

[0043] The data access conflict defect knowledge base construction module collects and extracts data access conflict defect code snippets to establish a structured defect case knowledge base.

[0044] The text block segmentation and word segmentation module: segments defect cases, ensures the integrity of text block context, and uses word segmentation strategies to process code and terminology;

[0045] The defect case knowledge base index module indexes the divided defect cases to improve the retrieval efficiency of subsequent queries.

[0046] The vectorization and retrieval module converts indexed defective cases into vector form, supporting efficient similarity retrieval.

[0047] The data access conflict detection module performs vector similarity retrieval based on the query content and generates a report of potential data access conflicts.

[0048] The conflict detection result sorting and reasoning module sorts the search results and generates the final conflict detection results and analysis report through reasoning.

[0049] This invention also provides applications of the above-mentioned detection method or detection system in real-time operating system development, embedded device software optimization, automotive electronic system security assurance, industrial automation control system, aerospace software development, etc.

[0050] The beneficial effects of this invention are as follows: This invention provides a data access conflict defect detection method based on a large language model. Addressing the problems of traditional detection methods, such as their inapplicability to highly complex software, high false negative rates, and low coverage (existing technologies have an average false negative rate as high as 20% and a false positive rate as high as 30%; while the method of this invention reduces the false negative rate to 10% and the false positive rate to 20%), this invention, by combining traditional static analysis techniques and code slicing techniques, proposes for the first time a data access conflict detection method based on retrieval-enhanced generation and fine-tuning of a large language model. This method supports the accurate identification of potential data access conflict defects in highly complex, large-scale code, providing a guarantee for the development of high-quality real-time embedded system software.

[0051] In addition, the present invention has the following other beneficial effects:

[0052] High adaptability and scalability: By fine-tuning the large language model, this invention can adapt to different programming languages ​​and diverse coding styles, and is applicable to embedded system software of various types and sizes, significantly improving the versatility and applicability of the tool.

[0053] Improved intelligence and automation: The introduction of retrieval-enhanced generation technology enables the model to automatically acquire and utilize the latest codebase and knowledge base information, further enhancing the intelligence level of defect detection, reducing manual intervention, and increasing automation.

[0054] Convenient integration and deployment: The modular design of the detection system of this invention has clear interfaces between modules, which facilitates seamless integration with existing development toolchains and continuous integration systems, simplifies the deployment process, and accelerates the application and promotion of tools. Attached Figure Description

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

[0056] Figure 1 This is a flowchart illustrating the data access conflict detection method based on a large language model provided by the present invention.

[0057] Figure 2 This is a flowchart illustrating the method provided by the present invention for selecting the set of shared variables GV most likely to have atomicity violation defects from the initial set of shared variables IG.

[0058] Figure 3 This is a schematic diagram illustrating the multi-turn dialogue-based progressive prompting process for completing a task, as provided by the present invention.

[0059] Figure 4 This is a schematic diagram of the Retrieval Enhancement Generation (RAG) method for defect detection provided by the present invention. Detailed Implementation

[0060] The present invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the present invention are all common knowledge and general knowledge in the art, and the present invention does not have any particular limitations.

[0061] This invention proposes a data access conflict defect detection method based on a large language model, relating to the field of software code analysis. The specific method includes: analyzing the code under test using static analysis tools to identify shared variables and their read / write information; extracting function slices containing read / write operations of shared variables from the code under test; using a large language model generated and fine-tuned after retrieval enhancement to perform data access conflict detection on the function slices and outputting the detection results. This invention also discloses a detection system implementing the above detection method, with wide application scenarios. This invention can effectively support data access conflict defect detection in highly complex software, helping to improve the accuracy of data access conflict defect detection and providing important support for the development and maintenance of high-quality concurrent software.

[0062] This invention provides a data access conflict detection method based on a large language model, comprising the following steps:

[0063] Step 1: Use static analysis tools to analyze the code under test, identify the shared variables and their read / write information in the code under test; use static analysis tools to perform syntax parsing and abstract syntax tree (AST) construction, variable identification and classification, function call and control flow analysis;

[0064] Step 2: Extract function slices containing shared variable read / write operations from the code under test;

[0065] Step 3: Input the data access conflict detection prompt engineering template and function slices into the large language model after retrieval enhancement and fine-tuning, perform data access conflict detection, and output the detection results.

[0066] Furthermore, in step one, the static analysis tool analyzes the program's source code to identify information such as variables, function calls, data flow, and control flow.

[0067] The shared variable refers to a variable that different execution units access simultaneously in a concurrent execution environment, used to pass information or status between different tasks; in specific implementation, the shared variable may include global variables, static variables, or variables shared through certain synchronization mechanisms (such as locks);

[0068] The read / write information includes the type of operation performed by each execution unit on the shared variable.

[0069] Furthermore, step two specifically includes the following steps:

[0070] Step 2.1: Based on the known entry points of the main function and the interrupt function, filter and summarize the initial shared variable set IG that is read and written in the main function and the interrupt function;

[0071] Step 2.2: Based on the atomicity violation rules for data access conflicts, filter the set of shared variables GV in IG that are most likely to have atomicity violation defects;

[0072] Three memory access operations can produce 8(2) 3 There are 4 different combinations of data access conflicts. Four of these combinations may lead to harmful data race defects, while the other four may involve data races but do not constitute defects. Therefore, data access conflicts can be mainly categorized into the following four types:

[0073] ① Read-Write-Read (RWR): When a low-priority task reads a global variable multiple times, it is interrupted by a high-priority interrupt's write operation on the variable, and subsequent reads by the low-priority task become invalid.

[0074] ②Write-Write-Read (WWR): The hardware disable signal of a low-priority task is overwritten by a high-priority interrupt, causing the high-priority write to be invalid.

[0075] ③ Read-Write-Write (RWW): A low-priority task's read and write operations on a port are interrupted by a high-priority interrupt, rendering the high-priority write invalid.

[0076] ④ Write-Read-Write (WRW): When a low-priority task is processing a variable, it is interrupted by a high-priority interrupt, causing the high-priority read to fail.

[0077] Step 2.3: Analyze the function call relationship based on the call graph of the code under test, and extract the function entry point of each shared variable in GV and the function slice in its call chain.

[0078] Furthermore, in step 2.1, the main function is usually the entry point of the program, while the interrupt function is usually a specific function called when an interrupt occurs. These functions may read and write shared variables.

[0079] By analyzing the code of the main function and the interrupt function, the variables that are read and written in the main function and the interrupt function are identified, and these shared variables that are read and written in the main function and the interrupt function are summarized to form an initial set of shared variables.

[0080] Furthermore, step 2.2 specifically includes the following steps:

[0081] Step 2.2.1: Determine whether the initial shared variable set IG has been traversed. If so, end the shared variable filtering; otherwise, select a shared variable sv from the initial shared variable set IG in order and continue to step 2.2.2.

[0082] Step 2.2.2: Determine whether the interrupt function of the shared variable sv contains at least one read or write operation of the shared variable; if a read or write operation of the shared variable sv is found in at least one interrupt function, proceed to step 2.2.3; if no read or write operation of the shared variable sv is found in any interrupt function, return to step 2.2.1 and select the next shared variable to check.

[0083] Step 2.2.3: Determine whether the main function of the shared variable sv contains at least one read or write operation on the shared variable; if there is at least one read or write operation on the shared variable sv in the main function, then proceed to step 2.2.4; if there is no read or write operation on the shared variable sv in the main function, then return to step 2.2.1 and select the next shared variable to check.

[0084] Step 2.2.4: Determine whether the shared variable sv is not limited to read or write operations in all interrupt functions and the main function; if the shared variable sv is not limited to read or write operations in all relevant functions (for example, there are complex operations such as condition judgment, modification, and calculation on the shared variable sv), then continue to step 2.2.5; if it is only read and write operations in all functions, then return to step 2.2.1 and continue to check other shared variables.

[0085] Step 2.2.5: Determine if the total number of operations on the shared variable sv in all interrupt functions and the main function is at least three; if the total number of operations on the shared variable sv in all relevant functions is at least three, then continue to step 2.2.6; if the total number of operations is less than three, then return to step 2.2.1 and check other shared variables.

[0086] Step 2.2.6: When the shared variable sv only involves read operations in the interrupt function, determine whether there are at least two write operations on the shared variable in the main function. If the shared variable sv only involves read operations in the interrupt function and there are at least two write operations in the main function, then the shared variable sv is considered a shared variable that may have atomicity violations and is added to the shared variable set GV. If the condition is not met, return to step 2.2.1 and continue to check other shared variables.

[0087] The code representation of selecting the set of shared variables most likely to have an atomicity violation defect from the initial set of shared variables is as follows:

[0088]

[0089]

[0090]

[0091]

[0092]

[0093] Furthermore, in step 2.3, based on the call graph analysis of the code under test, the function call relationships are analyzed, and the function entry points of each shared variable in GV and the function slices in its call chain are extracted. The specific implementation is as follows:

[0094] Function call relationship analysis and function slice extraction

[0095] 1. Graph construction:

[0096] Call Graph Construction: First, a call graph of the code under test is constructed using static analysis tools. A call graph is a graphical representation of function call relationships in a program; nodes represent functions, and edges represent function call relationships. Through the call graph, the call paths and hierarchical relationships between functions can be clearly understood.

[0097] 2. Function entry point identification:

[0098] Entry point identification: For each shared variable sv in the shared variable set GV, identify its entry point in each related function. The entry point is the specific location where the function begins execution, usually the function definition.

[0099] 3. Function slice extraction:

[0100] Definition and retrieval of o function slices:

[0101] Function slice: A function slice is a collection of code segments in a program that are related to a specific function or variable. It includes the function itself and all code parts in its call chain that directly or indirectly affect the shared variable sv.

[0102] Acquisition method: By calling graph analysis, starting from the entry point of each shared variable sv, traversing upwards and downwards along the call chain, all functions and their code fragments related to sv are extracted to form function slices.

[0103] The purpose of o function slicing:

[0104] Context provided: Function slices provide the usage context of the shared variable sv at different function call levels, which helps to fully understand the read and write operations of sv and the data access conflicts that may be caused.

[0105] Defect localization: By analyzing function slices, the code locations where atomicity violations may occur can be located more accurately, improving the accuracy and efficiency of defect detection.

[0106] How to use the o function slice:

[0107] Input to the large language model: The extracted function slices will be used as context input to the large language model that has been retrieved, enhanced, and fine-tuned, helping the model to better understand the use cases of shared variables and potential conflict risks.

[0108] Support for inference analysis: The detailed code snippets in function slices provide rich contextual information for large language models, enabling them to perform deeper inference analysis and identify complex atomicity violation patterns.

[0109] 4. Storage and management of function slices:

[0110] o Storage format: Function slices are stored in a structured format, including function names, call relationships, code snippets and related comments, which facilitates subsequent retrieval and analysis.

[0111] o Management Mechanism: Establish an efficient management mechanism to ensure the traceability and maintainability of function slices, and support dynamic updates and expansions to adapt to the continuously evolving codebase and newly introduced shared variables.

[0112] Furthermore, step three specifically includes the following:

[0113] Define a data conflict detection prompt template, which includes four parts: analysis objective, atomicity violation problem domain, task execution steps, and structured output;

[0114] And / or,

[0115] Build a knowledge base of data access conflict defect cases;

[0116] And / or,

[0117] The data access conflict detection prompts the engineering template and function slices related to the shared variable set GV, which are then input into the fine-tuned large language model to implement data access conflict detection based on retrieval enhancement.

[0118] Specifically, the prompt project template consists of the following components:

[0119] 1. Analysis Objective: Define the specific objectives of the detection task, such as identifying atomicity violations of shared variables.

[0120] 2. Domain of atomicity violation problem: Defines in detail under what conditions an atomicity violation is considered to exist, including specific operation modes and conditions.

[0121] 3. Task Execution Steps: Describe the specific execution steps of the detection task, including data preprocessing, function slice extraction, model input, etc.

[0122] 4. Structured output: Define the output format and content of the detection results, such as conflict type, conflict code location, and repair suggestions.

[0123] The reason for constructing the prompt project template during the implementation of this invention is as follows:

[0124] Standardized testing process: By defining a unified prompt engineering template, the consistency and repeatability of the testing process are ensured.

[0125] • Improve detection efficiency: The template-based prompt design can quickly adapt to different detection tasks, reduce manual intervention, and improve detection efficiency.

[0126] • Enhanced model understanding: Clear task definitions and structured prompts help large language models understand detection requirements more accurately, thereby improving detection accuracy.

[0127] In this invention, the defect case knowledge base is a knowledge base specifically used to store and manage specific types of defect cases (such as data access conflict atomicity violation defects), containing detailed code snippets, defect patterns, triggering conditions, and remediation suggestions.

[0128] Furthermore, the process of building a knowledge base for data access conflict defect cases is as follows: Figure 4 As shown, the specific steps include the following:

[0129] Step 1: Input the code snippets of the data access conflict atomicity violation defect dataset into the general large language model, extract information such as code function, defect pattern, defect triggering code snippet, defect triggering conditions and detailed description, and establish a data access conflict defect case knowledge base;

[0130] Defect Case Knowledge Base Preparation: First, collect and organize code snippets from one or more code repositories that demonstrate atomicity violations of data access conflicts. These snippets should include known defect instances from actual production environments and cover different models and application scenarios as much as possible to ensure the diversity and universality of the case library.

[0131] Input to a general-purpose large language model: Input the above defective code snippet into a general-purpose large language model (such as GPT-4), which will automatically extract relevant information. This information includes, but is not limited to:

[0132] Code Functionality: Identify and describe the main function of the code snippet, such as variable initialization, data processing, I / O operations, etc.

[0133] Defect Patterns: Extract and summarize defect patterns from defect cases, namely four common atomicity violation access interleaving patterns: RWR, RWW, WRW, and WWR.

[0134] Defect-triggered code snippets: Extract the specific lines of code and read / write operations that cause the defect, and identify which part of the code will trigger the conflict;

[0135] Defect triggering conditions: List the necessary conditions or prerequisites for triggering the defect, including interruption status, code execution path, and operation sequence, etc.

[0136] Detailed description: Generates a comprehensive description of the defect, including potential impact, severity analysis, etc.

[0137] Establish a case knowledge base: Organize the extracted information in standard JSON format and store it in a structured database to form a data access conflict defect case knowledge base;

[0138] Step II: Divide the knowledge base content by setting text box size, text block overlap processing and word segmentation strategy, and establish a knowledge base index for data access conflict defect cases.

[0139] Text block segmentation: Based on the extracted information, the content in the knowledge base is divided into one or more text blocks. Each text block can contain a specific functional description, defect pattern, trigger condition, or code snippet. During the segmentation process, reasonable text box sizes are used to ensure that each text block contains sufficient contextual information for subsequent retrieval and analysis.

[0140] Overlapping processing and word segmentation strategies: For text blocks with complex functional or defect descriptions, overlapping areas between text blocks are set to maintain semantic continuity and avoid information loss. Meanwhile, for content dense with code and technical terms, a specialized word segmentation strategy is employed, processing elements such as code variables, function names, keywords, and operators separately to generate word segmentation results suitable for the technical field.

[0141] By optimizing the word segmentation strategy, we can ensure that code elements and technical terms are accurately identified in the model input, thereby improving the accuracy of semantic understanding.

[0142] Indexing: The segmented text blocks are indexed to create a knowledge base index of data access conflict defect cases. This index structure allows for quick location of text blocks relevant to specific queries, improving retrieval efficiency.

[0143] Step III: Convert the indexed data access conflict defect knowledge case database into vector form to build a data access conflict defect vector database, supporting efficient similarity retrieval.

[0144] Vectorization Transformation: The indexed data access conflict defect case knowledge base is further converted into vector form. Embedding technology is used to map text information, code snippets, functional descriptions, and other content into a high-dimensional vector space. These vectors preserve the semantic relationships and contextual connections of the text, supporting subsequent efficient retrieval operations.

[0145] Vector Database Construction: The transformed vector data is stored in a vector database. This database supports similarity calculation between vectors and can quickly respond to retrieval requests. During the design process, appropriate vector distance metrics (such as cosine similarity) and vector indexing algorithms (such as Faiss) are selected to optimize retrieval speed and accuracy.

[0146] Furthermore, step III specifically includes the following steps:

[0147] Step 3.3.1: Convert the query content in the prompt information generated based on the data access conflict detection prompt project template and the function slice related to the shared variable set GV into vector form.

[0148] The query content (such as code snippets or descriptive text) in the prompt message is converted into a vector representation. At this point, each query content becomes a fixed-length vector, representing its position in a high-dimensional space and reflecting its semantic or functional characteristics.

[0149] Step 3.3.2: Perform vector similarity retrieval methods such as sparse retrieval (e.g., BM25) and dense retrieval (e.g., bge-large) from multiple dimensions such as code function, defect-triggered code snippets, and defect-triggered conditions.

[0150] Step 3.3.3: Perform preliminary and fine sorting on the vector similarity retrieval results. Input the top-ranked results as background knowledge along with prompt words into the large language model. Output the final data access conflict detection results through the reasoning and analysis of the large model.

[0151] Finely sorted code snippets and defect triggering conditions are used as background information and fed into a pre-trained (or fine-tuned) large language model along with the original prompts. This background knowledge helps the model better understand the context and task requirements, thereby improving the accuracy of reasoning. By comprehensively analyzing the input prompts and background knowledge, the large language model performs the reasoning process and ultimately generates a fault detection report that includes potentially conflicting code snippets and conflict types. Figure 1 In this context, coarse ranking (preliminary ranking) refers to using sparse retrieval methods (such as BM25) to quickly filter the vectorized search results, primarily based on keyword matching and document relevance scores. Fine ranking (refined ranking), on the other hand, employs intensive retrieval methods (such as BGE-Large), combining semantic embedding and contextual understanding to perform deep ranking of the initially filtered results, improving relevance and accuracy.

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

[0153] Example

[0154] This embodiment discloses a data access conflict defect detection method based on a large language model, such as... Figure 1 As shown, it can be used in fields such as real-time operating system development, embedded device software optimization, automotive electronic system security assurance, industrial automation control systems, and aerospace software development;

[0155] Includes the following steps:

[0156] 1) Figure 2 This document illustrates a flowchart illustrating a method for selecting the set of shared variables (GV) most likely to contain atomic violation defects from the initial set of shared variables (IG). For large software programs with tens of thousands of lines of code and hundreds of shared variables, directly slicing all detected shared variables into functions and submitting them to a large language model for further testing is impractical. Therefore, this embodiment proposes a coarse screening method based on four types of atomic violation access interleaving patterns. The specific process is as follows:

[0157] Initial Shared Variable Set Extraction: All shared variables are extracted from the software program's source code and stored in a JSON document, forming the Initial Shared Variable Set (IG). This JSON document contains information related to the shared variables, such as entryName (function entry point), funcName (called function name), accessRecords (read / write operation records), line (line number of the read / write operation), and accessType (read / write operation type).

[0158] Access Interleaving Pattern Analysis: By analyzing four common atomicity violation access interleaving patterns (RWR, RWW, WRW, WWR), the key variables and operation types affecting atomicity violations are extracted.

[0159] Output: The final set of shared variables (GV) most likely to have atomicity violation defects is selected, providing a basis for subsequent defect detection.

[0160] 2) Figure 3This document illustrates a flowchart of a multi-turn dialogue process using progressive prompts to complete a task. This embodiment introduces a method for interacting with a large language model through multi-turn dialogue, using progressive prompts to guide the large model step-by-step through a complex defect detection task. The specific steps are as follows:

[0161] Define the analysis objectives:

[0162] User instructions: In this step, the user first specifies the goal of the defect detection. For example, the user instruction could be "detect atomicity violation defect patterns".

[0163] Large Model Response: The large model understands user instructions and initializes the task. At this stage, the model prepares to analyze the overall structure and context of the code in order to perform the detection task more accurately in subsequent steps.

[0164] Identify and list all shared variables and their types:

[0165] User instruction: The user requests the large language model to identify all shared variables involved in the code and list these variables and their type information.

[0166] Large Model Response: The large model extracts and identifies all shared variables from code slices and provides the user with the variable names and their data types. For example, the model might identify globalvar1 as an int type and globalarray as an array of size 10000.

[0167] Identify the functions and code snippets that access these variables:

[0168] User instructions: The user further instructs the large model to identify all functions and code segments that access these shared variables.

[0169] Large model response: The large model finds the access points of each shared variable in the code and analyzes their context. For example, globalvar1 is written under a specific condition, and globalvar2 is accessed multiple times in a specific function.

[0170] Assess the potential impact of other Interruption Service Routines (ISRs) on these operations:

[0171] User instructions: The user instructs the large model to evaluate the impact of possible Interrupt Service Routine (ISR) operations on read and write operations of shared variables.

[0172] Large Model Response: The large model analyzes the code path and assesses the potential impact of ISR on these operations. For example, the model might identify that read operations on globalvar1 could be interrupted by ISR 1, while write operations on globalvar2 could not be interrupted by ISR 2.

[0173] Conditions for performing the analysis operation:

[0174] User instruction: The user requests that the large model analyze the preconditions for each operation in order to determine its feasibility.

[0175] Large model response: The large language model combines conditional statements and logical paths to analyze the execution conditions of each operation. For example, the model may determine that globalvar1 can be executed without any preconditions, while globalvar2 cannot be executed due to insufficient conditions (condition=0, which does not meet the condition=1).

[0176] like Figure 1 As shown, the core reasoning analysis and report generation for data access conflict defect detection based on a large language model are closely integrated with upstream steps, as detailed below:

[0177] 1) Input prompt project:

[0178] The prompting engineering designed in the upstream steps provides initial prompting information for the large language model, namely, prompting words for language defect detection in the large model;

[0179] 2) Retrieve from the defect vector database:

[0180] Combined with the prompting process, the model searches within a pre-built defect case knowledge base;

[0181] The knowledge base content has been vectorized and indexed to achieve efficient semantic matching and extract relevant cases and code snippets;

[0182] 3) Preliminary sorting and fine sorting:

[0183] The search results are first sorted (e.g., using sparse search methods);

[0184] The results after the initial screening are then finely sorted (e.g., using intensive retrieval methods) to ensure that the most relevant cases and background information are selected;

[0185] 4) Large language model reasoning analysis:

[0186] Input the sorted background information and prompts into the large language model;

[0187] Through the model's reasoning analysis, combined with the retrieval results and context, a detailed analysis and inference about potential defects are generated;

[0188] 5) Defect detection report generation:

[0189] The results of the reasoning and analysis are integrated into the final defect detection report;

[0190] The report includes specific code snippets of potential conflicts, the type of conflict, the conditions that may trigger it, and remediation suggestions to help users quickly locate and resolve the problem.

[0191] To further improve the accuracy of model analysis, the large language model can be fine-tuned or retrieval augmentation generation (RAG) technology can be introduced. RAG combines matching results from the knowledge base with model generation capabilities, making the output more targeted and context-relevant.

[0192] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of this invention are included in this invention and are protected by the appended claims.

Claims

1. A method for detecting data access conflict defects based on a large language model, characterized in that, Includes the following steps: Step 1: Use static analysis tools to analyze the code under test and identify the shared variables and read / write information in the code under test; Step 2: Extract function slices containing shared variable read / write operations from the code under test; Step 3: Input the data access conflict detection prompt engineering template and function slices into the large language model after retrieval enhancement and fine-tuning, perform data access conflict detection, and output the detection results.

2. The detection method according to claim 1, characterized in that, In step one, the static analysis tool parses the program's source code to identify information including variables, function calls, data flow, and control flow. And / or, The shared variables refer to variables that different execution units access simultaneously in a concurrent execution environment, used to pass information or status between different tasks; the shared variables include global variables, static variables, and variables shared through synchronization mechanisms; And / or, The read / write information includes the type of operation performed by each execution unit on the shared variable.

3. The detection method according to claim 1, characterized in that, Step two specifically includes the following sub-steps: Step 2.1: Based on the known entry points of the main function and the interrupt function, filter and summarize the initial shared variable set that is read and written in the main function and the interrupt function; Step 2.2: Based on the atomicity violation rules for data access conflicts, select the set of shared variables most likely to have atomicity violation defects from the initial set of shared variables; the atomicity violation rules include read-write-read, write-write-read, read-write-write, and write-read-write data race defects; Step 2.3: Analyze the function call relationship based on the call graph of the code under test, and extract the function entry point of each shared variable in the set of shared variables and the function slices in its call chain.

4. The detection method according to claim 3, characterized in that, Step 2.2 specifically includes the following sub-steps: Step 2.2.1: Determine whether the initial set of shared variables has been traversed. If so, end the shared variable filtering; otherwise, select a shared variable from the initial set of shared variables in order and continue to step 2.2.

2. Step 2.2.2: Determine whether the interrupt function of the shared variable contains at least one read or write operation of the shared variable. If yes, continue to step 2.2.3; otherwise, return to step 2.2.

1. Step 2.2.3: Determine whether the main function of the shared variable contains at least one read or write operation on the shared variable. If yes, continue to step 2.2.4; otherwise, return to step 2.2.

1. Step 2.2.4: Determine whether the shared variable is not limited to read or write operations in all interrupt functions and the main function. If so, continue to step 2.2.5; otherwise, return to step 2.2.

1. Step 2.2.5: Determine if the total number of operations on the shared variable in all interrupt functions and the main function is at least three. If yes, continue to step 2.2.6; otherwise, return to step 2.2.

1. Step 2.2.6: When a shared variable involves only read operations in the interrupt function, determine whether there are at least two write operations on the shared variable in the main function. If so, add the shared variable to the set of shared variables most likely to have an atomicity violation defect; otherwise, return to step 2.2.

1. And / or, In step 2.3, a call graph of the code under test is constructed using static analysis tools. For each shared variable in the shared variable set GV, its entry point in the relevant function is identified, and the position where the function starts to execute is determined. Through call graph analysis, starting from the entry point of the shared variable, the call chain is traversed upwards and downwards to extract all functions and their code fragments related to the shared variable, forming a function slice. And / or, The function slices are stored in a structured format.

5. The detection method according to claim 1, characterized in that, In step three, Define a data conflict detection prompt template, which includes four parts: analysis objective, atomicity violation problem domain, task execution steps, and structured output; And / or, Build a knowledge base of data access conflict defect cases; And / or, The data access conflict detection prompts the function slices related to the engineering template and shared variable set, which are then input into the fine-tuned large language model to implement data access conflict detection based on retrieval enhancement.

6. The detection method according to claim 5, characterized in that, Building a knowledge base of data access conflict defect cases includes the following steps: Step 1: Input the code snippets of the data access conflict atomicity violation defect dataset into the general large language model, extract information including code function, defect pattern, defect triggering code snippet, defect triggering condition and detailed description, and build a data access conflict defect case knowledge base; Step II: Divide the knowledge base content by setting text box size, text block overlap processing and word segmentation strategy, and establish a knowledge base index for data access conflict defect cases; Step III: Convert the indexed data access conflict defect knowledge case base data into vector form to construct a data access conflict defect vector database.

7. The detection method according to claim 6, characterized in that, In step I, the defect case knowledge base is a knowledge base for storing and managing defect cases, including code snippets, defect patterns, triggering conditions, and remediation suggestion information; The code functionality identifies and describes the function of the code snippet; The defect pattern is extracted and summarized from defect cases; The defect-triggered code snippet extracts the specific line of code and read / write operations that cause the defect, clearly identifying the code that will trigger the conflict. The defect triggering conditions list the necessary conditions or prerequisites for triggering defects, including interruption status, code execution path, and operation sequence. The detailed description generates a comprehensive description of the defect, including potential impact and severity analysis. And / or, In step II, the text block division divides the information in the knowledge base into one or more text blocks according to the different types of content. Each text block contains a specific functional description, defect pattern, triggering condition or code snippet to ensure the integrity of the context and facilitate subsequent retrieval. The overlapping processing and word segmentation strategy ensures semantic continuity in complex descriptions and correctly handles code and technical terms by setting overlapping areas between text blocks and adopting specialized word segmentation strategies, thereby optimizing subsequent analysis and retrieval. The indexing process involves indexing the divided text blocks, thereby improving query efficiency and quickly locating text blocks related to a specific query through the index structure. And / or, The word segmentation strategy refers to processing elements including code variables, function names, keywords, and operators separately to form word segmentation results suitable for the technical field.

8. The detection method according to claim 6, characterized in that, Step III specifically includes the following steps: Step 3.3.1: Convert the query content in the prompt information generated based on the data access conflict detection prompt project template and the function slice related to the shared variable set into vector form; Step 3.3.2: Perform vector similarity retrieval from multiple dimensions, including code function, defect-triggered code snippets, and defect-triggered conditions; Step 3.3.3: Sort the vector similarity retrieval results, and output the top-ranked retrieval results as the final data access conflict detection results using a large language model.

9. A detection system for implementing the detection method according to any one of claims 1-8, characterized in that, The monitoring system includes: a data access conflict detection template construction module, a data access conflict defect knowledge base construction module, a text block segmentation and word segmentation module, a defect case knowledge base indexing module, a vectorization and retrieval module, a data access conflict detection module, and a conflict detection result sorting and reasoning module. The data access conflict detection template construction module defines the detection framework and rules, and constructs the basic engineering template for data access conflict detection. The data access conflict defect knowledge base construction module collects and extracts data access conflict defect code snippets to establish a structured defect case knowledge base. The text block segmentation and word segmentation module: segments defect cases, ensures the integrity of text block context, and uses word segmentation strategies to process code and terminology; The defect case knowledge base index module indexes the divided defect cases to improve the retrieval efficiency of subsequent queries. The vectorization and retrieval module converts indexed defective cases into vector form, supporting efficient similarity retrieval. The data access conflict detection module performs vector similarity retrieval based on the query content and generates a report of potential data access conflicts. The conflict detection result sorting and reasoning module sorts the search results and generates the final conflict detection results and analysis report through reasoning.

10. The application of the detection method according to any one of claims 1-8, or the detection system according to claim 9, in real-time operating system development, embedded device software optimization, automotive electronic system security assurance, industrial automation control system, and aerospace software development.

Images