Multi-step agent based application program analysis method, device, equipment and medium

Abstract

Embodiments of the present application provide a kind of application program analysis method, device, equipment and medium based on multi-step intelligent agent, belong to program analysis technical field.The method includes: the source code of application program is carried out code structure identification, generates concurrent structure index;Through the first preset intelligent agent, the shared resource identification is carried out based on source code and concurrent structure index, and candidate shared resource is obtained;Through the second preset intelligent agent, based on candidate shared resource, the code slice of candidate shared resource is retrieved from source code;Through the third preset intelligent agent, based on candidate shared resource and code slice, access event for candidate shared resource is enumerated in code slice, and the resource sharing label of candidate shared resource is generated, and thread sharing abstract is obtained;Access event corresponding to candidate shared resource marked with target sharing label in thread sharing abstract is carried out race detection, and target race data is obtained.The accuracy of race detection can be improved by the embodiments of the present application.

Description

Technical Field

[0001] This application relates to the field of program analysis technology, and in particular to a method, apparatus, device and medium for application analysis based on multi-step intelligent agents. Background Technology

[0002] In related technologies, race condition detection is performed on program code to determine whether data races exist. Race condition detection can be achieved through dynamic analysis tools, static analysis tools, or manual code review. When using dynamic analysis tools for race condition detection, the program needs to be successfully compiled and executed, and the analysis coverage is affected by test inputs and thread scheduling. While static analysis tools do not require program execution, they are prone to generating numerous false positives due to pointers, aliases, function pointers, callbacks, cross-file calls, and complex synchronization semantics. Manual code review relies on expert experience and struggles to reliably identify cross-file, cross-function, and implicit sharing relationships in large-scale codebases. Therefore, improving the accuracy of race condition detection has become a pressing issue. Summary of the Invention

[0003] The main objective of this application is to propose an application analysis method, apparatus, device, and medium based on multi-step intelligent agents, aiming to improve the accuracy of competitive state detection.

[0004] To achieve the above objectives, a first aspect of this application proposes an application analysis method based on a multi-step intelligent agent, the method comprising: Obtain the application's source code; The source code is subjected to code structure identification, and a concurrent structure index is generated; Candidate shared resources are obtained by identifying shared resources based on the source code and the concurrent structure index using a first preset intelligent agent; The second preset intelligent agent retrieves code slices that access the candidate shared resources from the source code based on the candidate shared resources; A third preset intelligent agent, based on the candidate shared resources and the code slice, enumerates access events for the candidate shared resources in the code slice and generates resource sharing tags for the candidate shared resources to obtain a thread sharing summary; wherein, the resource sharing tags include target sharing tags; Race condition detection is performed on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared summary to obtain the target race condition data.

[0005] In some embodiments, the step of identifying candidate shared resources by a first preset intelligent agent based on the source code and the concurrent structure index includes: The first preset intelligent agent marks the global variables, static variables, file scope objects, and singleton states of the source code based on the source code and the concurrent structure index, and determines the initial shared resources according to the global variables, static variables, file scope objects, and singleton states. The first preset intelligent agent expands the initial shared resource based on the source code, the concurrent structure index, and the initial shared resource to obtain a first intermediate shared resource, and extracts the reference code statement that triggers the resource expansion from the source code according to the first intermediate shared resource; The first preset intelligent agent performs thread reachability verification on the first intermediate shared resource based on the source code, the concurrent structure index, and the first intermediate shared resource to obtain the second intermediate shared resource; The candidate shared resources are obtained by the first preset intelligent agent summarizing the resources based on the initial shared resources, the first intermediate shared resources, the reference code statements, and the second intermediate shared resources.

[0006] In some embodiments, the step of using a third preset intelligent agent to enumerate access events for the candidate shared resources in the code slice based on the candidate shared resources and the code slice, and generating resource sharing tags for the candidate shared resources to obtain a thread sharing summary includes: The third preset intelligent agent scans the code slice line by line, and outputs the access event based on the code statement that hits the candidate shared resource. The access events are grouped according to the resource identity of the candidate shared resources by the third preset intelligent agent to obtain access groups; The resource sharing tag is generated by the third preset intelligent agent based on the access type field and thread entry field of the access event in the access group; Generate the thread sharing summary based on the access event and the resource sharing tag.

[0007] In some embodiments, generating the resource sharing tag by the third preset intelligent agent based on the access type field and thread entry field of the access event in the access group includes: The third preset intelligent agent filters the access events based on the thread entry field of the access events in the access group and outputs a set of access threads. The third preset intelligent agent filters the access events based on the access type field of the access events in the access group and outputs a read / write set. The critical access set is determined based on the access thread set and the read / write set; The resource sharing tag is generated based on the synchronization context field of the access event in the key access set.

[0008] In some embodiments, the step of performing race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest to obtain target race condition data includes: Race condition verification is performed on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest, and candidate race condition data is generated; Convert the candidate competitive state data into logical constraints; The candidate competitive state data is obtained by verifying the state labeling of the candidate competitive state data based on the logical constraints using a preset solver.

[0009] In some embodiments, the step of identifying the code structure of the source code and generating a concurrent structure index includes: The source code is analyzed to identify the creation statements. The creation statement is extended for thread reachability to obtain the concurrent structure index.

[0010] In some embodiments, after performing race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest to obtain target race condition data, the method further includes: Obtain the candidate shared resource table, thread structure table, synchronization mode table, and candidate race state table obtained from the source code through multiple rounds of program analysis; Generate a thread sharing report based on the candidate shared resource table, the thread structure table, and the synchronization mode table; A data contention report is generated based on the candidate shared resource table, the thread structure table, the synchronization mode table, and the candidate race state table.

[0011] To achieve the above objectives, a second aspect of this application provides an application analysis apparatus based on a multi-step intelligent agent, the apparatus comprising: The acquisition module is used to acquire the application's source code; The first identification module is used to identify the code structure of the source code to obtain the concurrent structure; wherein the concurrent structure has a concurrent structure index; The second identification module is used to identify shared resources based on the source code and the concurrent structure index by a first preset intelligent agent, and obtain candidate shared resources; The retrieval module is used to retrieve code slices that access the candidate shared resources from the source code based on the candidate shared resources by a second preset intelligent agent; The summary generation module is used to enumerate access events for the candidate shared resources in the code slice based on the candidate shared resources and the code slice by a third preset intelligent agent, and generate resource sharing tags for the candidate shared resources to obtain a thread sharing summary; wherein, the resource sharing tags include target sharing tags; The race condition analysis module is used to perform race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest, and obtain the target race condition data.

[0012] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0013] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0014] The application analysis method, device, electronic device, and computer-readable storage medium based on multi-step intelligent agents proposed in this application, without requiring a strong dependency on a compilation and execution environment, use a multi-step intelligent agent as the scheduling core. It identifies candidate shared resources based on source code, retrieves code slices from the source code around these candidate shared resources, generates thread-shared summaries based on the code slices and candidate shared resources, and detects data race conditions based on these summaries. Instead of directly judging the entire program at once, it proceeds step-by-step in the order of concurrent structure identification, candidate shared resource identification, concurrent-aware slicing, shared summary generation, and race condition reasoning. This breaks down complex concurrency problems into multiple smaller steps, enabling the semantic understanding of the model, tool retrieval, and formal verification to work collaboratively. By combining the semantic understanding capabilities, code retrieval and slicing capabilities, and synchronous context analysis capabilities of the multi-step intelligent agent for code analysis, the accuracy of race condition detection is greatly improved. Attached Figure Description

[0015] Figure 1 This is a flowchart of the application analysis method based on a multi-step intelligent agent provided in the embodiments of this application; Figure 2 yes Figure 1 The flowchart of step S120 in the middle; Figure 3 yes Figure 1 The flowchart of step S130 in the process; Figure 4 yes Figure 1The flowchart of step S150 in the middle; Figure 5 yes Figure 4 The flowchart of step S430 in the middle; Figure 6 yes Figure 1 The flowchart of step S160 in the process; Figure 7 This is another flowchart of the application analysis method based on multi-step intelligent agents provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the application analysis device based on a multi-step intelligent agent provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0019] With the widespread application of multi-core processors, cloud computing platforms, high-concurrency servers, database systems, browser engines, operating system kernels, embedded systems, and high-performance computing programs, multithreaded concurrent programs have become an important way to improve the performance and throughput of modern software systems. Because C / C++ programs possess low-level memory control capabilities and high-performance characteristics, they are widely used in system software, infrastructure software, and industrial software. However, their concurrency behavior is often influenced by a variety of factors, including thread scheduling, shared memory access, synchronization mechanisms, object lifecycles, and pointer aliasing relationships.

[0020] In shared-memory concurrent programs, multiple threads may access the same memory resource through global variables, static variables, heap objects, struct fields, pointer indirection, container elements, thread entry parameters, callback functions, OpenMP parallel regions, and runtime library encapsulation. This type of thread-sharing behavior is the foundation of concurrent cooperation, but it is also a significant contributing factor to concurrency defects such as data races, atomicity violations, order violations, state inconsistencies, null pointer dereferencing, using already freed memory, and double-freeing.

[0021] Data races typically refer to two accesses from different threads operating on the same memory location, where at least one access is a write operation, and there is no sequential relationship between the two accesses established by locks, condition variables, barriers, thread creation and merging, atomic operations, or other synchronization mechanisms. Data races are characterized by low probability of triggering, strong thread scheduling dependence, difficulty in reproducing stable results, and difficulty in pinpointing the root cause. Even if a program runs without errors multiple times in normal tests, shared state corruption, incorrect results, or program crashes may occur under specific interleaved sequences.

[0022] In practical engineering, it's not only necessary to determine whether data races exist in the program, but also to understand other fundamental issues, such as which variables or objects are accessed by multiple threads, which source code locations are involved in thread sharing, from which threads or thread entry points these accesses originate, whether the access type is read or write, and whether there are synchronization contexts such as locks, waits, notifications, barriers, thread creation, or merging around the accesses. Only by obtaining the thread-shared structure can we further determine which shared accesses constitute unsynchronized conflicting accesses, which accesses, although shared, are protected by synchronization, and which accesses are more suitable as candidate locations for concurrency testing or code review.

[0023] Traditional analysis tools each have their limitations in addressing this problem. Dynamic analysis tools require successful compilation and execution of the target program, and their analysis coverage is affected by test inputs and thread scheduling; static analysis tools, although not requiring program execution, are prone to generating a large number of conservative false positives under C / C++ pointers, aliases, function pointers, callbacks, cross-file calls, and complex synchronization semantics; manual code review relies on expert experience and struggles to reliably identify cross-file, cross-function, and implicit sharing relationships in large-scale codebases.

[0024] Based on this, embodiments of this application provide an application analysis method, apparatus, device, and medium based on multi-step intelligent agents, aiming to improve the accuracy of competitive state detection.

[0025] The application analysis method, electronic device, and computer-readable storage medium based on multi-step intelligent agents provided in this application are specifically described through the following embodiments. First, the application analysis method based on multi-step intelligent agents in this application embodiment is described.

[0026] Figure 1 This is an optional flowchart of the application analysis method based on multi-step intelligent agents provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S110 to S160.

[0027] Step S110: Obtain the application's source code; Step S120: Identify the code structure of the source code and generate a concurrent structure index; Step S130: The first preset intelligent agent identifies shared resources based on source code and concurrent structure index to obtain candidate shared resources; Step S140: The second preset intelligent agent retrieves code slices from the source code that access candidate shared resources based on the candidate shared resources. Step S150: Based on candidate shared resources and code slices, the third preset intelligent agent enumerates access events for candidate shared resources in the code slices and generates resource sharing tags for candidate shared resources to obtain a thread sharing summary; wherein, the resource sharing tags include target sharing tags; Step S160: Perform race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared summary to obtain the target race condition data.

[0028] In step S110 of some embodiments, the source code of the application is obtained, and files, functions, variables, macros, call relationships, and reference location indexes are established. The application is a concurrent program to be analyzed, oriented towards C / C++, and the source code can be single-file source code, cross-file source code, etc.

[0029] In step S120 of some embodiments, concurrent structure identification is performed on the source code, identifying thread creation, task submission, parallel regions, thread entry points, synchronization primitives, and custom synchronization encapsulations, and generating a concurrent structure index.

[0030] Please see Figure 2 In some embodiments, step S120 may include, but is not limited to, steps S210 to S220: Step S210: Perform statement recognition on the source code to obtain creation statements and synchronization statements; Step S220: Generate a concurrent structure index based on the creation statement and the synchronization statement.

[0031] In step S210 of some embodiments, thread or task creation modes such as pthread_create, std::thread, OpenMP parallel, OpenMP task, asynchronous callback registration, and thread pool task submission in the source code are identified, and the thread entry function, task function, callback function, OpenMP parallel region, and thread pool task boundary are extracted to obtain the creation statement. Synchronization primitives such as mutexes, read-write locks, condition variables, semaphores, barriers, join, atomic, and critical regions in the source code are identified, and their corresponding functions are extracted to obtain the synchronization statement.

[0032] In step S220 of some embodiments, the function set reachable by each thread entry point is expanded by calling the graph and function reference relationships to form a thread reachability index. That is, starting with creation statements such as thread entry functions and task functions, the large language model is called to perform code retrieval on the source code. The prompt words require the large language model to list the downstream functions that the thread entry point can directly or indirectly call in the source code, so that the model outputs a candidate function list. The function names in the candidate function list are checked one by one against the source code symbol table, and function names that do not exist in the source code are eliminated. The set of functions that pass the check is the reachable function set of the thread entry point. The reachable function sets of all entry points together constitute the thread reachability index.

[0033] For pthread_mutex_lock / unlock, read-write locks, condition variables wait / signal / broadcast, sem_wait / sem_post, pthread_join, OpenMP barrier / critical / atomic, C / C++ atomic operations, and custom wrapper functions, a synchronization structure index is formed by recording the synchronization object, its source code location, the function it resides in, its entry and exit boundaries, and any possible happens-before or mutual exclusion relationships. The thread reachability index and the synchronization structure index together constitute the concurrency structure index. The thread reachability index is used to identify code regions where concurrent execution is possible. The synchronization structure index records the synchronization object and its scope, and can determine synchronization events that may establish order constraints between accesses.

[0034] Through the above steps S210 to S220, a concurrent structure index can be obtained, which can be used to locate concurrent structures in the source code.

[0035] In step S130 of some embodiments, the first preset intelligent agent is a shared resource identification intelligent agent, which is a large language model. The first preset intelligent agent performs structured step-by-step reasoning based on the source code and concurrent structure index. Each step of reasoning provides explicit judgment criteria to the intelligent agent in the form of prompt words, thereby outputting candidate shared resources. These candidate shared resources are stored in a candidate shared resource table. The candidate shared resource table includes multiple records, each record representing a candidate shared resource. Candidate shared resources include global variables, heap objects, fields, etc., obtained based on thread creation / entry points, shared object definitions, read / write access functions, and lock / condition variable encapsulation.

[0036] Please see Figure 3 In some embodiments, step S130 may include, but is not limited to, steps S310 to S340: Step S310: The first preset intelligent agent marks the global variables, static variables, file scope objects and singleton states of the source code based on the source code and the concurrent structure index, and determines the initial shared resources based on the global variables, static variables, file scope objects and singleton states; Step S320: The first preset intelligent agent expands the initial shared resources based on the source code, concurrent structure index and initial shared resources to obtain the first intermediate shared resources, and extracts the reference code statement that triggers the resource expansion from the source code according to the first intermediate shared resources; Step S330: The first preset intelligent agent performs thread reachability verification on the first intermediate shared resource based on the source code, concurrent structure index and the first intermediate shared resource to obtain the second intermediate shared resource; Step S340: The first preset intelligent agent summarizes the resources based on the initial shared resources, the first intermediate shared resources, the reference code statements, and the second intermediate shared resources to obtain candidate shared resources.

[0037] In step S310 of some embodiments, prompt words are constructed requiring the model to annotate global variables, static variables, file-scoped objects, and singleton states in the source code. A first preset agent, based on the source code, concurrency structure index, and prompt words, annotates the global variables, static variables, file-scoped objects, and singleton states in the source code. After judging each annotation according to the storage category keyword and scope of the variable declaration, the correctly judged annotations are used as initial shared resources. Initial shared resources are resources with a natural tendency to be shared, such as global variables, static variables, file-scoped objects, and singleton states.

[0038] In step S320 of some embodiments, the construction requirement model, based on the initial shared resources, combines the actual parameters passed in the thread creation statement, the return value propagation path of the heap allocation statement, the structure field access statement, the container element access statement, and pointer alias relationships to determine whether there are objects that have reached multiple threads through parameter passing, heap allocation, or pointer aliasing. The first preset agent, based on the source code, concurrent structure index, initial shared resources, and prompt words, determines the objects that have reached multiple threads from the initial shared resources to expand the resources, obtaining a first intermediate shared resource. For each newly added object, it extracts the statements that trigger the judgment from the source code to obtain reference code statements. The first intermediate shared resource is an object that has been propagated to multiple threads through thread entry parameters, heap objects, structure fields, container elements, callback contexts, or pointer aliases.

[0039] In step S330 of some embodiments, the thread reachability is used to determine whether a resource may be accessed by multiple threads or parallel tasks. A requirement model is constructed to verify, using the thread reachability index, whether the access location of each object in the first intermediate shared resource falls within the reachable function sets of two or more different thread entry points, and outputs a prompt word for objects that meet the conditions. The first preset agent performs thread reachability verification on the first intermediate shared resource based on the source code, the concurrency structure index, the first intermediate shared resource, and the prompt word, and designates objects falling within the reachable function sets as second intermediate shared resources.

[0040] In step S340 of some embodiments, prompt words for structured output are constructed. These prompt words require the model to organize the judgment results and evidence from the first three steps into a candidate shared resource table using a unified JSON template. The fields include resource name, resource type, definition location, possible aliases, related access locations, related thread entry points, and initial confidence level. The first preset agent summarizes resources based on the initial shared resources, first intermediate shared resources, reference code statements, second intermediate shared resources, and prompt words, outputting structured data to obtain candidate shared resources. Candidate shared resources include fields such as resource name, resource type, definition location, possible aliases, related access locations, related thread entry points, and initial confidence level. The initial confidence level is assigned a high, medium, or low rating by the model based on the directness of the evidence (reference code statements) from step S320. For example, direct evidence such as global variables is rated high, while multi-level pointer alias deduction is rated low.

[0041] The candidate shared resources output by the model are checked for field integrity and row number authenticity. Records that fail the check are returned and regenerated according to steps S310 to S340.

[0042] Through the above steps S310 to S340, based on the fact that shared resources are not a single variable name, but rather source code composed of resource identity, access events, read / write types, thread context, and synchronization context, the embodiments of this application pay attention to both variable names and heap objects, fields, array elements, and possible alias memory locations, avoiding using only text variables with the same name as the basis for sharing judgment.

[0043] In step S140 of some embodiments, the second preset agent is a concurrency-aware code slicing agent. The concurrency-aware code slicing agent performs the search centered on candidate shared resources, rather than on files or functions. The second preset agent uses each candidate shared resource in the candidate shared resource table as the search target, performs code retrieval on the source code, and extracts statements, functions, code regions, call chains, thread entry points, and synchronization contexts that access the candidate shared resources to obtain resource-level code slices.

[0044] In simple single-round prompts, directly inputting the entire program into the model and demanding data races as output is prone to problems. The model is susceptible to excessively long contexts, interference from irrelevant code, misleading local synchronization clues, and missing cross-file relationships. It may misjudge accesses actually protected by synchronization as race conditions, or overlook shared accesses hidden behind multi-file, multi-threaded entry points or wrapper layers. Simple, large language model prompts are prone to illusions and omissions, making it difficult to reliably perform thread-sharing and data race analysis. This slicing mechanism, however, allows the model to reason within a focused context around a single shared resource, rather than understanding all variables and threads simultaneously within the complete code context. This reduces the context size and interference from irrelevant code, thus compressing the whole-program-level analysis problem into a resource-level analysis problem.

[0045] For each candidate shared resource R, using R's identifier, known aliases, and field paths as search clues, a second pre-defined intelligent agent locates direct access, alias access, field access, array index access, address-of-reference (OIR), function parameter passing, return value propagation, and container-encapsulated access statements of R in the source code. The complete function body containing the matched statements and their direct call relationships are extracted to form the minimum relevant code fragment containing these accesses, resulting in a resource-level code slice. The resource-level code slice includes at least the following: read and write statements accessing R; the function and call chain containing the access; which thread entry points, task entry points, or parallel regions can reach the access; synchronization statements near the access such as locking, unlocking, waiting, notification, barrier, join, atomic, and critical; path conditions, loop boundaries, and index expressions that affect whether the access occurs; and assignment, address-of-reference, and parameter passing statements that may affect alias relationships.

[0046] In step S150 of some embodiments, a third preset agent generates a thread-shared digest. For a candidate shared resource R, the third preset agent enumerates access events a in a code slice and records the source file, line number, function name, access type, thread entry point, path condition, synchronization context, and evidence fragment for each access event. The code slice typically contains multiple read, write, fetch, or parameter-passing statements for R, each of which corresponds to an independent access event.

[0047] The third pre-defined agent, based on the thread entry information in candidate shared resources, enumerates and structurally records access events on code slices. It then adds resource-sharing tags to the candidate shared resources according to the accessing thread, read-write relationship, and synchronization state corresponding to each access event, resulting in a thread-sharing summary. Resource-sharing tags include target sharing tags, which are Shared and RW tags. Shared indicates sharing, and RW indicates write or compound update. The thread-sharing summary records shared resources, access locations, access types, accessing threads, synchronization context, and cross-file origins. The thread-sharing summary can serve as a report for developers to understand the program's concurrent structure, helping to identify which variables or objects participate in cross-thread interactions, which accesses are protected by synchronization, and which locations are suitable for code review or controlled concurrent testing. The thread-sharing summary can also serve as structured input for data race reasoning, reducing subsequent analysis's reliance on the full original source code. The summary fields and tag system provide a unified semantic representation for subsequent reasoning, preventing analysis results from remaining only at the level of scattered logs or address-level traces.

[0048] Please see Figure 4 In some embodiments, step S150 may include, but is not limited to, steps S410 to S440: Step S410: The third preset intelligent agent scans the code statements of the code slice line by line, and outputs access events based on the code statements that hit the candidate shared resources; Step S420: The access events are grouped according to the resource identity of the candidate shared resources by the third preset intelligent agent to obtain access groups; Step S430: The third preset intelligent agent generates a resource sharing tag based on the access type field and thread entry field of the access event in the access group; Step S440: Generate a thread-shared summary based on the access event and resource-shared tag.

[0049] In step S410 of some embodiments, the third preset agent scans the code statements in the code slice line by line according to the prompt words. If the code statement matches a candidate shared resource R, a known alias of R, or a field path, an access event is output. The fields recorded in the access event record include source file, line number, function name, access type (at least including read, write, read-write composite update, address fetch, parameter pass, and unknown access), thread entry field (the thread entry field associated with the candidate shared resource), path condition, synchronization context, and evidence fragment (the original text of the code statement). The line number and function name fields are verified against the source code item by item. Access event records that fail verification are marked as pending review and are not included in subsequent statistics.

[0050] In step S420 of some embodiments, the resource identity is used to identify the resource and is jointly determined by the variable definition location, field path, heap allocation point, alias set, array base address and index expression, thread entry parameter propagation path, etc. A prompt word is constructed to merge access events according to resource identity. The third preset agent groups all access events output within the same code slice according to resource identity based on the prompt word, resulting in access groups.

[0051] The third pre-defined agent compares the resource identities of each access event one by one to see if they are consistent. Access events with consistent identities are grouped under the same candidate shared resource R, but the content of each access event's own fields is not changed; only the grouping relationship is established.

[0052] It should be noted that for pointer or field accesses that cannot be fully resolved, the access event record is saved as a possible alias resource, and the confidence level and source of evidence are marked in the thread-shared summary. If the field or field path pointed to by the pointer in the access statement has multiple possible values ​​in the source code text, such as the pointer being reassigned in multiple places, or the array subscript depending on the runtime variable, the model cannot uniquely determine the specific resource identity accessed. Therefore, the access event is not classified into a specific identified resource, but is retained as an alias record that may be related to multiple candidate shared resources. The prompt requires the model to provide all candidate resource identities listed in the record, the specific statement that triggers the ambiguity judgment as the source of evidence, and to give a confidence level rating based on the number of candidate resource identities. If the resource identity is unique, the confidence level is determined to be high; if there are two resource identities, the confidence level is determined to be medium; if there are three or more resource identities, the confidence level is determined to be low.

[0053] In step S430 of some embodiments, the third preset agent reads the access type field and thread entry field of the access event in the access group, and generates a resource sharing label for the candidate shared resource R based on the access type field and thread entry field.

[0054] In step S440 of some embodiments, a thread sharing summary is generated based on the candidate shared resource, the access event corresponding to the candidate shared resource, and the resource sharing tag.

[0055] Through the above steps S410 to S440, a thread sharing digest can be obtained, which is used to perform data competition analysis. This establishes the data competition analysis on a clear sharing relationship, thereby providing data support for the data competition analysis.

[0056] Please see Figure 5 In some embodiments, step S430 may include, but is not limited to, steps S510 to S540: Step S510: The third preset intelligent agent filters the access events based on the thread entry field of the access events in the access group and outputs the access thread set. Step S520: The third preset intelligent agent filters the access events based on the access type field of the access events in the access group and outputs the read and write set. Step S530: Determine the key access set based on the access thread set and the read / write set; Step S540: Generate resource sharing tags based on the synchronization context field of the access events in the key access set.

[0057] In steps S510 to S520 of some embodiments, the third preset intelligent agent reads the thread entry field and access type field of the access events in the access group, deduplicates the field values ​​of the thread entry field of all access events under the access group to obtain the access thread set, and filters out the access events with the access type field as "write" or "update" into the read-write set.

[0058] In step S530 of some embodiments, if the number of thread entries in the access thread set is not less than two, and the third preset agent confirms through structured reasoning that there is no necessary strict order among these thread entries based on the join / wait relationship recorded in the synchronization structure index, then the candidate shared resource associated with the access group is tagged with Shared. If the read / write set is not empty, that is, there is at least one access event of the access type being write or compound update, then the candidate shared resource associated with the access group is tagged with RW. Access events that simultaneously satisfy the Shared and RW criteria are defined as critical accesses, that is, access events corresponding to candidate shared resources that are simultaneously tagged with Shared and RW are critical access events, thus obtaining the critical access set.

[0059] In step S540 of some embodiments, for each access event in the critical access set, the access is individually determined to be protected based on whether the synchronization context field of the access event is not empty. For any two access events that are both determined to be protected, the synchronization object identifiers recorded in their synchronization context fields are further compared to see if they are the same. If all access events in the critical access set are determined to be protected, and the synchronization object identifiers of any pairwise comparisons are the same, then it is determined that all critical accesses are protected by the same lock or the same synchronization mechanism, and the corresponding tags LockProtected (synchronization object type is lock protected), AtomicRelated (synchronization object type is atomic operation type), BarrierRelated (synchronization object type is barrier synchronization type), or WaitSignalRelated (synchronization object type is waiting signal type) are added according to the synchronization object type. If the critical access set contains both protected and unprotected access events, or if all access events are protected but the synchronization object identifiers for each pair are not completely consistent, then it is determined that some access is protected and some access is unprotected. In this case, the "Partially Protected" tag is added, and the specific reason (such as unprotected access or inconsistent protected objects) is noted in the evidence field. If all access events in the critical access set are unprotected, then it is determined that the critical access lacks interpretable synchronization protection, and the "Unprotected Shared" tag is added.

[0060] Through the above steps S510 to S540, resource sharing tags can be generated to identify objects participating in cross-thread interactions, access protected by synchronization, etc.

[0061] Please see Figure 6 In some embodiments, step S160 may include, but is not limited to, steps S610 to S630: Step S610: Perform race condition verification on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest, and generate candidate race condition data; Step S620: Convert the candidate competitive state data into logical constraints; Step S630: Verify the state labeling of the candidate competitive state data based on logical constraints using a preset solver to obtain the target competitive state data.

[0062] In step S610 of some embodiments, a data race reasoning agent is invoked to perform data race reasoning, identifying candidate conflicting access pairs from the thread shared digest. Data race reasoning is performed on access events corresponding to candidate shared resources marked with the target shared tag (Shared+RW) in the thread shared digest, rather than directly on the entire program text. Candidate shared resources marked only with ReadOnlyShared (excluding write access) are not included in data race reasoning.

[0063] For any two access events a1 and a2 corresponding to the same candidate shared resource R in the thread shared digest, four conditions are checked in sequence, and candidate race condition data is generated based on the access events that satisfy all four conditions. The four conditions are: (1) whether a1 and a2 come from different thread entry points, different OpenMP tasks, different asynchronous tasks, or paths that may be executed concurrently; (2) whether a1 and a2 act on the same variable, the same field, the same array element, the same set of objects, or possible alias memory locations; (3) whether at least one of a1 and a2 is a write access or a compound update; (4) whether a1 and a2 lack common lock protection, determine the order of access, or have atomic semantics. The candidate race condition data includes the shared resource, the location of the two access events, the access type, thread information, the reason for missing synchronization, relevant slice evidence, and the initial confidence level.

[0064] If two access events satisfy the sharing and read / write conditions, i.e., conditions (1), (2), and (3), but are protected by the same lock, the same critical region, join, barrier, wait / signal, or atomic semantics, then the access pair will not be output as an unsynchronized data race, but will be retained as a synchronized protected share in the thread sharing report. This design avoids simply equating all shared reads and writes with data races, and also explains why some shared resources, although read and written by multiple threads, will not ultimately appear in the data race report. For pointer aliases, structure fields, array indices, and compound updates commonly found in C / C++ programs, candidate inference results are further filtered by subsequent constraint verification.

[0065] In step S620 of some embodiments, the thread reachability, path conditions, alias relationships, read-write conflicts, lock holding states, etc., of the candidate race condition data are encoded into logical constraints. The constraints include thread reachability, path reachability, access to the same address or alias relationship, read-write conflict relationship, lock holding state, synchronization order relationship, circular index relationship, and scheduling interleaving feasibility. Thread reachability is used to constrain that the functions containing two accesses must be reached from the entry points of threads or tasks that may execute concurrently; path reachability is used to indicate the branch conditions and circular conditions that affect the execution of the access when it occurs; array or field access includes encoded index expressions, field paths, and alias relationships; synchronization protection is used to indicate whether the same mutex lock is held, whether they are located in the same critical region, or whether the order relationship is established by barrier, join, conditionwait / signal, or atomic operations when the encoded access occurs.

[0066] In step S630 of some embodiments, after converting candidate race states into logical constraints including thread reachability, access conflicts, synchronization protection, and scheduling feasibility, infeasible candidate race states are filtered and verified using a satisfiability modular theory solver to obtain target race state data. The satisfiability modular theory solver is used to determine whether feasible interleaving exists and outputs race states with verified verified states. The solution results of the satisfiability modular theory solver are divided into three categories: if the logical constraints can be satisfied, it means that there is a feasible interleaving that allows two conflicting accesses to simultaneously satisfy the race state conditions, and the candidate race state is marked as VerifiedFeasible; if the logical constraints cannot be satisfied, the candidate race state is marked as VerifiedInfeasible and filtered from the data race report; if the logical constraint construction fails, the solution times out, or there is insufficient information, the candidate race state is marked as UnverifiedConstraintFailed or NotChecked and is retained according to a conservative strategy or entered into the manual review queue.

[0067] It should be noted that SMT filtering does not require full-process accurate modeling of the complete C / C++ semantics. Instead, it cross-validates the key feasibility conditions in the candidate race conditions. This allows it to retain the semantic understanding advantages of large language models while avoiding complete reliance on the natural language judgment of the model, thus reducing illusory false positives in the reasoning of large language models.

[0068] Steps S610 to S630 above do not treat all shared access as a race condition. Instead, candidate conflicting access pairs are first identified at the summary level, and then verified through thread reachability, path conditions, alias relationships, and synchronization order constraints. This combines the semantic judgment of the large language model with the feasibility check of the solver, reducing hallucination false alarms.

[0069] Please see Figure 7 In some embodiments, after step S160, the application analysis method based on multi-step intelligent agents may also include, but is not limited to, steps S710 to S730: Step S710: Obtain the candidate shared resource table, thread structure table, synchronization mode table, and candidate race state table obtained from the source code through multiple rounds of program analysis; Step S720: Generate a thread sharing report based on the candidate shared resource table, thread structure table, and synchronization pattern table; Step S730: Generate a data competition report based on the candidate shared resource table, thread structure table, synchronization mode table, and candidate race state table.

[0070] In step S710 of some embodiments, for large multi-file projects that cannot be accommodated by a single context, the complete source code often cannot be input into the model all at once. This application's embodiments employ a multi-round context accumulation and result aggregation mechanism to maintain cross-round states, analyzing the source code round by round according to file, module, call cluster, or shared resource cluster, and maintaining four types of tables in the global state: candidate shared resource table, thread structure table, synchronization pattern table, and candidate race condition table. The candidate shared resource table records resource identity, definition location, alias set, accessed file, and access state; the thread structure table records thread entry point, task entry point, concurrent region, and reachable function set; the synchronization pattern table records lock objects, condition variables, barriers, atomic operations, custom synchronization encapsulations, and their scope; the candidate race condition table records access pairs that have been discovered but have not yet completed constraint verification or cross-file merging.

[0071] Based on the idea of ​​merging the results of multiple runs or rounds of analysis, after each round of analysis, the output of the model in that round is normalized into a unified structure and merged with the global state table. Specifically, if a new access to a previously shared resource appears in a subsequent file, the access set and synchronization context are updated; if a new synchronization wrapper function is identified in a subsequent file, the synchronization interpretation of existing candidate access pairs is updated backtrackingly; if duplicate candidates are generated in multiple rounds, they are deduplicated according to resource identity, access position, thread entry point, and synchronization context.

[0072] It should be noted that the merging object in this application embodiment is the source code-level agent analysis result, rather than the necessary runtime trajectory. This approach enables the handling of cross-file sharing and cross-file synchronization relationships even under context-window constraints.

[0073] In step S720 of some embodiments, candidate shared resources, code slices, thread sharing summaries, and candidate competition data (candidate race states) are continuously accumulated and merged during multi-turn dialogues to obtain a candidate shared resource table corresponding to the candidate shared resources, a thread structure table corresponding to the code slices, a synchronization pattern table corresponding to the thread sharing summaries, and a candidate race state table corresponding to the candidate competition data. After all files are processed, the thread sharing summaries are organized into a thread sharing report and output in a structured format such as JSON, tables, database records, HTML reports, or IDE-consumable formats. The thread sharing report is geared towards program understanding and shared structure review. The thread sharing summary may include the following fields: id (identifier), resource, resource_kind (resource type), definition_location (location definition), aliases, accesses (access events), threads, functions, sync_context (synchronization context), shared_tags (shared tags), evidence, and confidence. The `accesses` field can further include `file`, `line`, `function`, `access_kind`, `thread_entry`, `path_condition`, and `surrounding_sync`; `shared_tags` can include `Shared`, `RW`, `ReadOnlyShared`, `LockProtected`, `PartiallyProtected`, `UnprotectedShared`, `AtomicRelated`, `BarrierRelated`, `WaitSignalRelated`, etc.

[0074] In step S730 of some embodiments, the target competition data is organized into a data competition report and output in a structured format such as JSON, tables, database records, HTML reports, or IDE-consumable formats. The data competition report is for defect localization and risk remediation. The data competition report may include the following fields: id, resource, access_pair, race_type, missing_sync_reason, smt_status, feasible_interleaving, confidence, and evidence. smt_status can be VerifiedFeasible, VerifiedInfeasible, UnverifiedConstraintFailed, or NotChecked, used to distinguish between constraint-verified competition states, candidates proven untriggerable, and candidates conservatively retained due to insufficient constraints.

[0075] By using steps S710 to S730 above, the problem of maintaining cross-file sharing relationships in multi-file projects can be solved.

[0076] This application embodiment identifies the concurrent structure of the source code to be analyzed, obtaining a concurrent structure index including thread entry points, concurrent regions, and synchronization structures. Based on the concurrent structure index and source code, candidate shared resources are identified, resulting in a candidate shared resource table. Concurrency-aware code slicing is performed around the candidate shared resources to obtain a resource-level slice set. Access events of shared resources are enumerated based on resource-level slices, generating a thread-shared summary containing access location, access thread, read / write type, and synchronization context. Based on the thread-shared summary, a candidate data competition set is generated only for resources that satisfy sharing and have write access. Thread reachability, path conditions, alias relationships, read / write conflicts, and synchronization protection relationships in the candidate data competition are encoded as constraints and verified to obtain data competition results with verified status. The thread-shared summary and verified data competition results are organized into a structured thread-shared report and a data competition report. For large multi-file projects, candidate shared resources, shared summaries, and candidate competition results are continuously updated through multiple rounds of context accumulation and global state merging until a project-level analysis report is formed, outputting a structured report that can be directly consumed by developers and downstream tools.

[0077] Compared to simple static rules, dynamic instrumentation detection, or one-time model hints, this application provides interpretable, verifiable, and structured output of joint analysis results on thread sharing and data races for C / C++ concurrent programs without heavily relying on a complete compilation and execution environment. First, it enables concurrency analysis without strong reliance on compilation and execution. This application directly performs semantic reasoning and code slicing on the source code, making it suitable for projects lacking a complete build environment, with insufficient test input, or those difficult to run with traditional dynamic tools. Second, it can use thread sharing analysis as a prerequisite for data race analysis. This application first outputs shared resources, shared access locations, access threads, read / write types, and synchronization contexts, and then judges data races based on these, making the report more interpretable. Third, it can reduce contextual interference in large language model analysis. By using concurrency-aware slicing centered on shared resources, this application breaks down the entire program problem into multiple small-scale, highly correlated local problems, improving the stability of model inference. Fourth, it can reduce phantom false positives through SMT constraint verification. This application does not rely entirely on model judgment but instead delegates candidate race states to a symbolic constraint verification module for feasibility cross-checking, thereby filtering logically untriggerable candidates. Fifth, it supports cross-round analysis of multi-file projects. This application maintains shared resources, thread structure, synchronization mode, and candidate race conditions through a global state table, enabling the model to handle large projects within the context window constraint. Sixth, it can generate a unified structured output for developers and downstream tools. Both thread sharing reports and data race reports use parsable formats, facilitating integration with IDEs, code review platforms, testing frameworks, defect localization tools, and controlled scheduling tools. Seventh, it can complement traditional static and dynamic tools. This application is suitable for providing semantic assistance when traditional tools cannot compile, cannot execute, or have many false positives; it can also use the results of traditional tools as input clues to fuse with the shared summary and constraint filtering results of this application.

[0078] This application's embodiments use the source code to be analyzed as the main input and a multi-step intelligent agent as the scheduling core. It combines the semantic understanding, code retrieval and slicing capabilities, synchronous context analysis capabilities, and SMT constraint verification capabilities of a large language model. The code analysis is completed according to the following process: candidate shared resource identification, concurrency-aware code slicing, thread-shared summary generation, candidate data competition reasoning, constraint verification filtering, multi-file result aggregation, and structured report output. This application's embodiments do not directly require the model to provide a data competition conclusion for the complete program in a single prompt. Instead, it first identifies the thread-shared structure, then forms an interpretable source code-level summary around the shared resources, and finally performs race-state reasoning and formal filtering based on the summary. Therefore, thread-shared analysis is no longer just an intermediate byproduct of data competition detection, but becomes a fundamental technical result that can be independently output, reused, and audited. Unlike dynamic instrumentation-based thread-shared analysis, this application's embodiments do not require successful program compilation and execution as a necessary condition, making it suitable for scenarios lacking a complete build environment, insufficient test input, or only obtaining source code fragments. Dynamic analysis tools, static analyzers, or manually labeled results can serve as optional input clues for candidate generation or result verification, but they do not constitute essential steps in the execution flow of this application's embodiments. The feasibility and practical effects of this application's embodiments are verified below.

[0079] Verify object coverage The experimental subjects cover standard OpenMP concurrency micro-benchmarks, Linux kernel-level verification tasks, and real-world multi-file concurrency projects, totaling 3950 concurrent program files and approximately 1428.02 KLOCs of code, including typical synchronization structures such as mutexes, atomic operations, barriers, and condition variables. This scope indicates that the related processes in this application are not limited to a single example program, but can be used to analyze C / C++ concurrent programs of different scales and synchronization structures. The verification objects and their synchronization structure composition are shown in Table 1.

[0080] Table 1

[0081] Among them, DataRaceBench can be used to verify race condition identification and false alarm control capabilities under standard concurrent mode; LDV-linux-3.14 can be used to verify context compression and process stability under long code files; RaceBench can be used to verify risk screening capabilities and applicable boundaries in real multi-file engineering scenarios.

[0082] Multi-step analysis process improves false alarm control and overall detection effectiveness. This application's embodiments do not employ a one-time prompt model that directly provides conclusions. Instead, they break down concurrent analysis into steps such as candidate shared resource identification, resource-level slicing, shared summary generation, candidate race condition reasoning, and constraint filtering. Compared to direct prompts and single-round thought chain reasoning, the multi-step agent process significantly improves accuracy and reduces false alarm rates. The data race detection performance of different analysis processes is shown in Table 2.

[0083] Table 2

[0084] As shown in Table 2, the multi-step intelligent agent process improves the accuracy from approximately 48% to 84.4% and reduces the false alarm rate from 34.62% to 15.6%. This result demonstrates that by first forming shared resources and their access contexts, and then performing candidate race condition judgment and constraint filtering, this application can effectively reduce the misreporting of synchronous protection access, unreachable access, or infeasible intersection as data races.

[0085] Comparison with typical traditional tools On standard concurrency benchmarks, the multi-step agent process was compared with typical data contention detection tools such as ThreadSanitizer, OpenRace, and SVF. The results show that the process described in this application significantly improves precision and F1 score while maintaining high recall, making it suitable for providing risk analysis results in source code review scenarios lacking a complete compilation and execution environment or with insufficient test input. The comparison results on standard concurrency benchmarks are shown in Table 3.

[0086] Table 3

[0087] The above results demonstrate that the process described in this application does not simply increase the number of alerts, but rather improves alert quality through shared resource focusing, synchronous context identification, and candidate filtering. Traditional dynamic tools still have runtime evidence advantages on executed paths, while traditional static tools still have value in terms of conservative coverage; the advantage of this application lies in its ability to output thread-shared structure and data race risk reports at the source code level, reducing reliance on compilation, instrumentation, and test input.

[0088] Concurrency-aware slicing brings context compression and process stability This application employs concurrency-aware code slicing centered on candidate shared resources. This allows the model to extract access statements, thread entry points, call chains, synchronization contexts, and path conditions around shared resources, rather than processing the entire project or long file at once. This mechanism reduces the input size and improves the stability of multi-step analysis processes. The slicing efficiency results at the system level are shown in Table 4.

[0089] Table 4

[0090] As shown in Table 4, in a system-level code scenario with an average length of approximately 6.3 KLOC / file, concurrency-aware slicing can compress the effective context by 92.93% while maintaining a 100% task completion rate. This result directly supports the resource-level slicing mechanism in this application: by first identifying shared resources and then extracting the concurrency context associated with those resources, the pressure on the context window caused by long code files can be alleviated, and the interference of irrelevant code on model inference can be reduced.

[0091] Model implementation conditions and stability of structured output This application can be implemented using different large language models or models with equivalent semantic reasoning capabilities, but multi-step processes require the model to stably follow the steps, maintain contextual state, and output structured results. Related experiments show that model size and model capability significantly affect the completion rate and proportion of valid results in multi-step analysis processes. The performance of models of different sizes in executing multi-step analysis processes is shown in Table 5.

[0092] Table 5

[0093] Table 5 shows that small-scale models are prone to incomplete tasks or unparseable outputs when performing structured multi-step inference. When the model size reaches approximately 32 bytes, both the completion rate and Pass@5 scores significantly improve. This result indicates that when implementing this application, it is advisable to configure mechanisms such as output format validation, failure retry, and candidate result verification, and to prioritize models or combinations of models capable of stably completing multi-step inference and structured output. This result also shows that this application can select different models based on deployment cost, output stability, and analytical accuracy requirements, rather than being limited to a specific model.

[0094] Applicable effects under different concurrency modes The related experiments also statistically analyzed the detection accuracy of different methods according to concurrency modes. The results show that model methods and traditional tools are complementary under different concurrency modes: traditional dynamic tools perform better in some synchronous primitive modes, while multi-step semantic reasoning methods have advantages in scenarios requiring code semantic understanding, such as variable scoping and asynchronous task scheduling. The detection accuracy (%) under different concurrency modes is shown in Table 6.

[0095] Table 6

[0096] The results demonstrate the necessity of the thread-shared digest and data race joint analysis approach adopted in this application: relying solely on traditional syntax or runtime events may be insufficient to cover semantic information such as variable scope, asynchronous tasks, and encapsulated synchronization; relying solely on natural language judgments from the model may introduce errors in complex logic and precise feasibility. Therefore, this application combines semantic reasoning, structured digests, and constraint verification to improve applicability under different concurrency modes.

[0097] In summary, this application achieves the following practical effects: First, it improves the accuracy of data race analysis and reduces false positives through a multi-step intelligent agent process; second, it significantly compresses the context of long code files through resource-level concurrency-aware slicing, improving the stability of the analysis process; third, it structures shared resources, access threads, read / write types, and synchronization contexts through thread-shared summaries, facilitating manual review and subsequent race condition reasoning; fourth, it reduces infeasibility risk reports through candidate race condition reasoning and constraint filtering; and fifth, it supports cross-file sharing relationship analysis in real engineering projects through a multi-file state aggregation mechanism.

[0098] Please see Figure 8 This application also provides an application analysis device based on a multi-step intelligent agent, which can implement the above-mentioned application analysis method based on a multi-step intelligent agent. The application analysis device based on a multi-step intelligent agent includes: Module 810 is used to obtain the application's source code; The first identification module 820 is used to identify the code structure of the source code to obtain the concurrent structure; wherein the concurrent structure has a concurrent structure index; The second identification module 830 is used to identify shared resources based on source code and concurrent structure index by the first preset intelligent agent to obtain candidate shared resources; The retrieval module 840 is used to retrieve code slices that access candidate shared resources from the source code based on candidate shared resources by a second preset intelligent agent. The summary generation module 850 is used to obtain a thread-shared summary by using a third preset intelligent agent to enumerate access events for candidate shared resources in the code slices based on candidate shared resources and code slices; and to generate resource sharing tags for candidate shared resources; wherein the resource sharing tags include target sharing tags. The race condition analysis module 860 is used to perform race condition detection on the access events corresponding to candidate shared resources marked with the target shared tag in the thread shared summary, and obtain the target race condition data.

[0099] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described application analysis method based on a multi-step intelligent agent. This electronic device can be any intelligent terminal, including tablet computers, in-vehicle computers, etc.

[0100] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 910 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 920 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 920 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 920 and is called and executed by the processor 910 using the application analysis method based on a multi-step intelligent agent according to the embodiments of this application. The input / output interface 930 is used to implement information input and output; The communication interface 940 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 950 transmits information between various components of the device (e.g., processor 910, memory 920, input / output interface 930, and communication interface 940); The processor 910, memory 920, input / output interface 930 and communication interface 940 are connected to each other within the device via bus 950.

[0101] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described application analysis method based on a multi-step intelligent agent.

[0102] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0103] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0104] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0105] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0107] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0108] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0110] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0111] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0112] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0113] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. An application analysis method based on multi-step intelligent agents, characterized in that, The method includes: Obtain the application's source code; The source code is subjected to code structure identification, and a concurrent structure index is generated; Candidate shared resources are obtained by identifying shared resources based on the source code and the concurrent structure index using a first preset intelligent agent; The second preset intelligent agent retrieves code slices that access the candidate shared resources from the source code based on the candidate shared resources; A third preset intelligent agent, based on the candidate shared resources and the code slice, enumerates access events for the candidate shared resources in the code slice and generates resource sharing tags for the candidate shared resources to obtain a thread sharing summary; wherein, the resource sharing tags include target sharing tags; Race condition detection is performed on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared summary to obtain the target race condition data.

2. The method according to claim 1, characterized in that, The step of identifying candidate shared resources by a first preset intelligent agent based on the source code and the concurrent structure index, including: The first preset intelligent agent marks the global variables, static variables, file scope objects, and singleton states of the source code based on the source code and the concurrent structure index, and determines the initial shared resources according to the global variables, static variables, file scope objects, and singleton states. The first preset intelligent agent expands the initial shared resource based on the source code, the concurrent structure index, and the initial shared resource to obtain a first intermediate shared resource, and extracts the reference code statement that triggers the resource expansion from the source code according to the first intermediate shared resource; The first preset intelligent agent performs thread reachability verification on the first intermediate shared resource based on the source code, the concurrent structure index, and the first intermediate shared resource to obtain the second intermediate shared resource; The candidate shared resources are obtained by the first preset intelligent agent summarizing the resources based on the initial shared resources, the first intermediate shared resources, the reference code statements, and the second intermediate shared resources.

3. The method according to claim 1, characterized in that, The process involves a third pre-defined intelligent agent enumerating access events for the candidate shared resources within the code slices based on the candidate shared resources and the code slices, generating resource sharing tags for the candidate shared resources, and obtaining a thread sharing summary, including: The third preset intelligent agent scans the code slice line by line, and outputs the access event based on the code statement that hits the candidate shared resource. The access events are grouped according to the resource identity of the candidate shared resources by the third preset intelligent agent to obtain access groups; The resource sharing tag is generated by the third preset intelligent agent based on the access type field and thread entry field of the access event in the access group; Generate the thread sharing summary based on the access event and the resource sharing tag.

4. The method according to claim 3, characterized in that, The step of generating the resource sharing tag by the third preset intelligent agent based on the access type field and thread entry field of the access event in the access group includes: The third preset intelligent agent filters the access events based on the thread entry field of the access events in the access group and outputs a set of access threads. The third preset intelligent agent filters the access events based on the access type field of the access events in the access group and outputs a read / write set. The critical access set is determined based on the access thread set and the read / write set; The resource sharing tag is generated based on the synchronization context field of the access event in the key access set.

5. The method according to claim 1, characterized in that, The step of performing race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest to obtain target race condition data includes: Race condition verification is performed on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest, and candidate race condition data is generated; Convert the candidate competitive state data into logical constraints; The candidate competitive state data is obtained by verifying the state labeling of the candidate competitive state data based on the logical constraints using a preset solver.

6. The method according to any one of claims 1 to 5, characterized in that, The step of identifying the code structure of the source code and generating a concurrent structure index includes: The source code is analyzed to identify creation statements and synchronization statements. The concurrent structure index is generated based on the creation statement and the synchronization statement.

7. The method according to any one of claims 1 to 5, characterized in that, After performing race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest to obtain the target race condition data, the method further includes: Obtain the candidate shared resource table, thread structure table, synchronization mode table, and candidate race state table obtained from the source code through multiple rounds of program analysis; Generate a thread sharing report based on the candidate shared resource table, the thread structure table, and the synchronization mode table; A data contention report is generated based on the candidate shared resource table, the thread structure table, the synchronization mode table, and the candidate race state table.

8. An application analysis device based on a multi-step intelligent agent, characterized in that, The device includes: The acquisition module is used to acquire the application's source code; The first identification module is used to identify the code structure of the source code to obtain the concurrent structure; wherein the concurrent structure has a concurrent structure index; The second identification module is used to identify shared resources based on the source code and the concurrent structure index by a first preset intelligent agent, and obtain candidate shared resources; The retrieval module is used to retrieve code slices that access the candidate shared resources from the source code based on the candidate shared resources by a second preset intelligent agent; The summary generation module is used to enumerate access events for the candidate shared resources in the code slice based on the candidate shared resources and the code slice by a third preset intelligent agent, and generate resource sharing tags for the candidate shared resources to obtain a thread sharing summary; wherein, the resource sharing tags include target sharing tags; The race condition analysis module is used to perform race condition detection on the access events corresponding to the candidate shared resources marked with the target shared tag in the thread shared digest, and obtain the target race condition data.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images