KR20200077297A - Method and Apparatus for detecting atomicity violation for shared memory used in multi-process/multi-thread - Google Patents

Abstract

According to the present invention, provided is a method for detecting an atomicity violation defect for a shared memory used in a multi-process/multi-thread. The method comprises: a shared memory analysis step of pre-analyzing a shared memory before executing a process and extracting a function pair which should access the shared memory atomically, wherein the function pair is associated with a shared memory atomic pair; an execution log collection step of calling a function to access the analyzed shared memory and collecting execution information of each process/thread; and a defect analysis step for analyzing a defect using the execution information and the shared memory atomic pair. Shared memory calls which should be atomisticaly made are analyzed through pre-binary analysis, and the shared memory calls are applied to execution data analysis obtained through hooking, so that atomicity violations in a shared memory can be detected.

Description

Method and Apparatus for detecting atomicity violation for shared memory used in multi-process/multi-thread}

The present invention relates to a method and apparatus for detecting atomic violation defects in shared memory. More particularly, the present invention relates to a method and apparatus for detecting an atomic violation defect for shared memory used by multi-process/multi-thread.

Recently, a multi-CPU environment has been generalized. On the other hand, in one CPU environment, there was no true concurrency even if it was a multi-thread. Therefore, the probability of a defect occurring due to a race condition between threads or processes was very low. However, as the multi-CPU environment is generalized, concurrency bugs, such as multiple CPUs accessing shared resources at the same time or changing the execution order of threads, are more frequently occurring.

Concurrent defects can be classified into deadlock, atomicity violation, and ordering violation. Once a parallel defect occurs, the program simply stops or ends, or it can seriously cause a human accident, such as a radioactive accident. Therefore, testing is one of the very serious flaws that need to be focused. However, since concurrent systems have a non-deterministic execution characteristic in which the scheduling of a process or a thread can be changed even in the same execution, it is difficult to predict the concurrency defect occurring in a specific execution situation of the system in advance, and a defect occurs It is also not easy to find the cause and reproduce the situation when debugging a defect.

Among the parallel defects, the atomic violation is a defect that has a high incidence and must be solved. Deadlocks or sequence violations have limited functions that can cause defects, and once a defect occurs, hang or crash. However, the atomic violation does not stop or shut down the system by itself because another operation is intervened in the access operation that should be treated as one operation in shared memory. In addition, there is a problem in that it is difficult to determine the defect as an atomic violation even if a defect is detected because the influence of the wrong approach is indeterminate.

Various methods for detecting atomic violations of shared memory have been studied. Atomic violation may detect defects through execution-based dynamic analysis rather than static analysis, since the occurrence of defects may vary depending on the execution environment.

Most atomic violation detection methods analyze locks used for synchronization to detect atomic violation defects in shared memory protected by locks. In this regard, multi-threaded programs monitor shared memory access between threads to detect atomic violations. It is a method to detect whether a thread is protected by a lock, or whether another thread accesses the shared memory or shared variable as a defect. In addition, after analyzing the variables used for synchronization, it was proposed to analyze the execution of the program to detect atomic violation defects. However, the method of detecting a defect by analyzing the variable used for synchronization has a problem in that it cannot detect an atomic violation defect occurring in a shared memory area that is not protected by the synchronization variable.

In addition, by adding lock/unlock code for the read/write function, it is possible to consider a method of detecting an atomic violation defect for a current read/write target. However, this method has a problem in that it breaks the original execution environment because it is a method of changing the execution binary.

It is an object of the present invention to provide a method and apparatus for detecting an atomic violation defect for shared memory used in multi-process/multi-thread.

In addition, it is an object of the present invention to provide a method and apparatus for detecting an atomic violation of a shared memory by pre-analyzing the shared memory before executing the process and analyzing it together with the execution log.

A method for detecting an atomic violation defect for a shared memory used in a multi-process/multi-thread according to the present invention for solving the above problems is provided. The method includes: a shared memory analysis step of pre-analyzing shared memory and extracting a function pair that needs to be atomically accessed to the shared memory before the process is executed, wherein the function pair is associated with a shared memory atomic pair; An execution log collection step of calling a function to access the analyzed shared memory and collecting execution information of each process/thread; And a defect analysis step of analyzing a defect using the execution information and the shared memory atomic pair, analyzing a shared memory call that needs to be made atomistic through dictionary binary analysis, and applying it to analysis of execution data obtained through hooking. It can detect atomic violations of shared memory.

According to an embodiment of the present disclosure, the execution log collection step may monitor a read/write function call to collect execution logs accessing the shared memory while minimizing the impact on the execution environment. At this time, the collected execution information may include the parameter value used in the read/write function and the ID and state of each process/thread as execution information of each process/thread.

According to one embodiment, the defect analysis step, after the execution of the system under test is finished, the parameter value used in the read/write function, the ID and state of each process/thread with execution information of each process/thread And the shared memory atomic pair can be used to analyze defects.

According to an embodiment, in the defect analysis step, the execution log of the read/write function is collected and analyzed, and read() or write of Thread 2 is performed before read() of Thread 1 is performed and write() is performed. When the function () is performed, it can be determined as an atomic violation defect candidate for the shared memory.

According to an embodiment, when global variables used in Thread 1 and Thread 2 are used in both the first function and the second function executed by Thread 1 and Thread 2, read() of Thread 1 When the read() or write() function of Thread 2 is performed before is executed and write() is performed, it may be determined as an atomic violation defect candidate for the shared memory in the defect analysis step.

According to an embodiment, when the global variable used in Thread 1 and Thread 2 is used in both the first function and the second function executed by Thread 1 and Thread 2, write() of Thread 1 When the read() of the Thread 2 is called before the execution is performed, the multi-process/multi-thread control step of controlling the read() of the Thread 2 to be performed after the write() of the Thread 1 is performed further includes can do.

According to an embodiment, in the multi-process/multi-thread control step, when the read() or write() function of Thread 2 is performed before the write() of Thread 1 is performed, the write() of Thread 1 ) To change the global variable according to the characteristic changed by ), and to perform read() of Thread 2 again according to the changed global variable.

A device for detecting an atomic violation defect for shared memory used in multi-process/multi-thread according to another aspect of the present invention is provided. The apparatus comprises: a shared memory configured to be accessible by multi-process/multi-thread, and storing variables and information; A shared memory analysis module that pre-analyzes the shared memory and extracts a function pair that needs to be atomically accessed to the shared memory before the process is executed-the function pair is associated with a shared memory atomic pair; An execution log collection module that calls a function to access the analyzed shared memory and collects execution information of each process/thread; And a defect analysis module for analyzing defects using the execution information and the shared memory atomic pair.

According to one embodiment, the execution log collection module may monitor a read/write function call in order to collect execution logs accessing the shared memory while minimizing the impact on the execution environment. At this time, the collected execution information may include the parameter value used in the read/write function and the ID and state of each process/thread as execution information of each process/thread.

According to an embodiment of the present disclosure, after the execution of the system under test is completed, the defect analysis module uses parameter values used in the read/write function and ID and status of each process/thread as execution information of each process/thread. And the shared memory atomic pair can be used to analyze defects.

According to an embodiment, in the execution log collection module, the execution log of the read/write function is collected, and in the defect analysis module, before the read() of Thread 1 is performed and the write() is performed, Thread 2 When the read() or write() function is performed, it can be determined as an atomic violation defect candidate for the shared memory.

According to an embodiment, in the defect analysis module, global variables used in Thread 1 and Thread 2 are used in both the first function and the second function executed by Thread 1 and Thread 2, and the atomicity If it is determined as a violation defect candidate, if the read() of the thread 2 is called before the write() of the thread 1 is performed, the read() of the thread 2 after the write() of the thread 1 is performed It may further include a process / thread control to control the execution.

According to the present invention, there is an advantage in that it is possible to detect an atomic violation of the shared memory by analyzing the shared memory call that needs to be made atomistic through dictionary binary analysis and applying it to the execution data analysis obtained through hooking.

In addition, according to the present invention, it is advantageous in that a false positive rate is low because it reduces the range in which an atomic violation detection can occur through pre-analysis and analyzes based on a situation in which an actual process/thread is executed.

In addition, according to the present invention, there is an advantage in that the runtime state can be maintained as there is less overhead due to the method of detecting the test object without changing it.

The present invention can be variously changed and can have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

1 is a diagram for a method of accessing a shared memory managed by an OS according to the present invention.
2 is a diagram for a method of sharing and using global variables according to the present invention.
3 is a view for explaining an embodiment of the atomic sharing violation according to the present invention.
4 is a flowchart of an atomic violation defect detection method for shared memory used in multi-process/multi-thread according to the present invention.
5 shows a detailed configuration of an atomic violation defect detection apparatus according to the present invention.

The above-described features and effects of the present invention will become more apparent through the following detailed description in connection with the accompanying drawings, and accordingly, those skilled in the art to which the present invention pertains can easily implement the technical spirit of the present invention. Will be able to.

The present invention can be variously changed and can have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

In describing each drawing, similar reference numerals are used for similar components.

Terms such as first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from other components.

For example, the first component may be referred to as a second component without departing from the scope of the present invention, and similarly, the second component may be referred to as a first component. The term and/or includes a combination of a plurality of related described items or any one of a plurality of related described items.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person skilled in the art to which the present invention pertains.

Terms such as those defined in a commonly used dictionary should be interpreted as having meanings consistent with meanings in the context of related technologies, and should not be interpreted as ideal or excessively formal meanings unless explicitly defined in the present application. Should not.

The suffix modules, blocks, and parts for components used in the following description are given or mixed only considering the ease of writing the specification, and do not have a meaning or a role that is distinguished from each other.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described so that those skilled in the art can easily carry out. In the following description of embodiments of the present invention, when it is determined that detailed descriptions of related well-known functions or well-known configurations may unnecessarily obscure the subject matter of the present invention, detailed descriptions thereof will be omitted.

Hereinafter, a method and apparatus for detecting an atomic violation defect for a shared memory used in a multi-process/multi-thread according to the present invention will be described in detail.

1 is a diagram for a method of accessing a shared memory managed by an OS according to the present invention. Referring to FIG. 1, a shared memory may be allocated through a call to a shared memory management function provided by an OS and released after being used.

2 is a diagram for a method of sharing and using global variables according to the present invention. Referring to FIG. 2, global variables that can be accessed from anywhere in a program can be used as shared memory between threads because multiple threads within a process can access them.

3 is a view for explaining an embodiment of the atomic sharing violation according to the present invention. Specifically, FIG. 3 shows source code in a multi-threaded environment configured to cause an atomic sharing violation according to the present invention.

Hereinafter, with reference to FIGS. 1 to 3, a method and apparatus for detecting an atomic violation defect for a shared memory used in a multi-process/multi-thread according to the present invention will be described.

Specifically, the present invention proposes a method of detecting an atomic violation of the shared memory by pre-analyzing the shared memory before executing the process and analyzing it together with the execution log.

In this regard, FIG. 4 shows a flowchart of an atomic violation defect detection method for a shared memory used in a multi-process/multi-thread according to the present invention. Referring to FIG. 4, the method for detecting an atomic violation defect includes a shared memory analysis step (S110 ), an execution log collection step (S120 ), a defect analysis step (S130 ), and a multi-process/multi-thread control step (S140 ).

In the shared memory analysis step (S110), the shared memory is pre-analyzed before the process is executed, and a function pair that needs to be atomically accessed is extracted. At this time, the function pair is associated with the shared memory atomic pair.

In the execution log collection step (S120 ), a function is called to access the analyzed shared memory, and execution information of each process/thread is collected. At this time, in the execution log collection step (S120 ), a read/write function call may be monitored to collect execution logs accessing the shared memory while minimizing the impact on the execution environment. Accordingly, the collected execution information may include the parameter value used in the read/write function and the ID and state of each process/thread as execution information of each process/thread.

In the defect analysis step (S130), the defect is analyzed using the execution information and the shared memory atomic pair. Specifically, in the defect analysis step (S130), after the execution of the system under test is finished, the defect may be analyzed. To this end, after the execution of the system under test is terminated, using the parameter value used in the read/write function, the ID and status of each process/thread as the execution information of each process/thread, and the atomic pair of the shared memory Defects can be analyzed.

Meanwhile, a specific method of the determination method as a candidate for an atomic violation defect in the defect analysis step S130 is as follows. In this regard, execution logs of the read/write function may be collected and analyzed in the defect analysis step (S130). In addition, in the defect analysis step (S130), if read() or write() function of Thread 2 is performed before read() of Thread 1 is performed and write() is performed, atomic violation of the shared memory It can be judged as a defect candidate.

Specifically, when global variables used in Thread 1 and Thread 2 are used in both the first function and the second function executed by Thread 1 and Thread 2, it can be determined as an atomic violation defect candidate. . Accordingly, when the global variable is used in both the first and second functions, and the read() or write() function of Thread 2 is executed before the read() of Thread 1 is performed and the write() is performed. , In the defect analysis step (S130), it may be determined as an atomic violation defect candidate for the shared memory.

Meanwhile, a detailed operation of the above-described shared memory analysis step (S110), execution log collection step (S120), and defect analysis step (S130) is as follows.

<Step 1. Shared memory analysis (S110)>

There are two ways to use shared memory in a process/thread. The first method is to create and use the shared memory by calling the shared memory creation function provided by the OS, and the second is to create a global variable inside the process and share it in multi-thread.

In the first method, the shared memory managed by the OS is used as shown in FIG. 1 through a function call related to the shared memory. Linux provides shared memory management functions such as shmget, shmat, and shmdt. When shared memory is created through the Shmget function, the shared memory space is allocated by the Linux kernel, and access to the process can be added/released through the shmat/shmdt function.

Second, a method of using a global variable like a shared memory is shown in FIG. 2. The variables used in the program are largely divided into local variables that can be called only within a specific function and global variables that can be accessed from any function. Global variables are variables stored in the data area of the process, and cannot be accessed from other processes, but can be shared because they can be accessed from any function within one process.

After the shared memory analysis is over, a function pair that needs to be accessed atomically is extracted. First, when an area bound by lock/unlock of a resource access restriction function such as pthread_mutex_lock/unlock exists, the internal shared memory access protected by lock/unlock is stored as a “shared memory atomic pair”. When access to the shared memory occurs more than once within a function even in areas not protected by lock/unlock, the continuous shared memory access is stored as a “shared memory atomic pair candidate”.

<Step 2. Collect execution log (S120)>

In order to access the shared memory analyzed in the'Shared Memory Analysis' step, there is a method of calling a function such as read/write or reading and writing a value directly to a shared memory variable. In order to monitor the shared memory variable itself, the overhead for monitoring increases, which can break the real-time execution environment and is not suitable for detecting defects based on execution. Therefore, read/write function calls are monitored to collect execution logs that access shared memory with minimal impact on the execution environment.

In this case, the information to be collected should not only collect parameter values used in read/write functions, but also process/thread execution information. This is because, in the case of concurrency defects, such as an atomic violation of shared memory, whether a defect occurs depends on the execution status of a process or thread. That is, since the occurrence of a defect depends on the execution environment of the process or thread, in order to detect the defect, it is necessary to collect execution information of the process/thread as well as a function call to access the shared memory.

Process/thread execution information includes the ID and status of each process/thread. In addition, you should also collect the time to check in what order the process/thread was executing when the read/write function call occurred. In this regard, information collected inside and outside of the read/write function is shown in Table 1 below.

function Information collected inside the function Information collected outside the function Read Read function call time, buf to be read Process ID, thread ID, process status, thread status write Write function call time, buf to be written Process ID, thread ID, process status, thread status

<Step 3. Defect analysis (S130)>

After the execution of the system under test is completed, defects are analyzed using the collected execution log and the previously analyzed'shared memory atomic pair'. In the case of an atomic violation defect, it is indeterminate that it should be analyzed more than once. When analyzing the execution log, if the function call to access the shared memory is a function call corresponding to the'shared memory atomic pair', if there is a call to another access function during execution, it is determined as an atomic violation defect. When a function call corresponding to the “shared memory atomic pair candidate” is accessed from another process/thread, it is determined as an atomic violation defect candidate.

<Example>

As described above, FIG. 3 is a diagram illustrating an embodiment of an atomicity violation according to the present invention. Specifically, FIG. 3 shows source code in a multi-threaded environment configured to cause an atomic sharing violation according to the present invention.

The variables bal used in Thread 1 and Thread 2 are global variables, and inside the Bank_update() and Bank_Withdraw() functions must be executed as a single operation. However, since the execution of the thread is not completely guaranteed and is not protected by a lock, an atomic violation may occur if a context switch occurs during thread execution.

In the present invention, the global variable bal is analyzed as the shared memory through the pre-analysis of the shared memory. Then, through the code analysis of Bank_Update() and Bank_Withdraw(), the operation to access bal is extracted and stored as a'shared memory atomic pair candidate'.

After collecting the execution log of the function, if the read() or write() function of Thread 2 is executed before the read() of Thread 1 is executed and the write() is executed, it is a candidate for an atomic violation defect. It is judged as.

On the other hand, based on this principle, a method for determining a specific atomic violation defect candidate and a control method for preventing an atomic violation from occurring or a control method for a shared violation will be described.

In this regard, when the global variables used in Thread 1 and Thread 2 are used in both the first function and the second function executed by Thread 1 and Thread 2, the multi-process/multi-thread control step (S140) ) Can be performed. In the multi-process/multi-thread control step (S140), when the read() of the thread 2 is called before the write() of the thread 1 is performed, the thread 2 after the write() of the thread 1 is performed You can control the read() to be performed. Therefore, there is an advantage in that the execution of the Thread 2 is temporarily suspended, and the Thread 2 can be executed according to the global variable changed by reflecting the execution result of the Thread 1.

On the other hand, when the read() or write() function of Thread 2 is performed before the write() of Thread 1 is performed, a multi-process/multi-thread control step S140 may be performed. At this time, in the multi-process/multi-thread control step (S140), the global variable is changed according to the characteristic changed by the write() of the thread 1, and the read() of the thread 2 is read again according to the changed global variable. It can be controlled to perform. Therefore, even if the thread 2 is already executed and an atomic sharing violation occurs, there is an advantage that the thread 2 can be re-executed by compensating it after the thread 1 is completed.

In the above, the method for detecting an atomic violation defect for the shared memory used in the multi-process/multi-thread according to the present invention has been described. Hereinafter, an atomic violation defect detection apparatus for shared memory used in multi-process/multi-thread according to another aspect of the present invention will be described.

In this regard, the description of the method for detecting an atomic violation defect described above is also applicable to the device for detecting an atomic violation defect. On the other hand, the atomic violation defect detection device may be any control device, computer, control unit, processor, etc. that detects the atomic violation defect. Specifically, the atomic violation defect detection device may be any control device, computer, control unit, processor, or the like equipped with any OS or program capable of detecting such atomic violation defects.

In this regard, FIG. 5 shows a detailed configuration of an atomic violation defect detection apparatus according to the present invention. Referring to FIG. 5, the shared memory 110, the shared memory analysis module 120, the execution log collection module 130, the defect analysis module 140 and the process/thread control unit 150 are included.

Here, referring to the shared memory 110 as shown in FIG. 3, a configuration for performing Process A performing multi-threading may be referred to as a first processor (or first controller). On the other hand, as illustrated in FIG. 5, a configuration for detecting and controlling shared memory violation according to the process/thread controller 150 may be referred to as a second processor (or second controller). At this time, some of the shared memory analysis module 120, the execution log collection module 130, and the defect analysis module 140 may be performed by the first processor, and the rest may be performed by the second processor. For example, the shared memory analysis module 120 may be performed by the first processor, and the execution log collection module 130 and the defect analysis module 140 may be performed by the second processor. However, the implementation method is not limited thereto, and may be changed according to application.

Meanwhile, the first and second processors (or the first and second controllers) are logically or functionally separated, and may be physically implemented as a single processor.

The shared memory 110 is configured to be accessible by multi-process/multi-thread, and can store variables and information. The shared memory analysis module 120 is configured to pre-analyze the shared memory before executing a process and extract a function pair that needs to be atomically accessed to the shared memory. At this time, the function pair is associated with the shared memory atomic pair.

The execution log collection module 130 is configured to call a function to access the analyzed shared memory and collect execution information of each process/thread. Specifically, the execution log collection module 130 may be configured to monitor read/write function calls to collect execution logs accessing the shared memory while minimizing the impact on the execution environment. At this time, the collected execution information may include the parameter value used in the read/write function and the ID and state of each process/thread as execution information of each process/thread.

In addition, the defect analysis module 140 analyzes a defect using the execution information and the shared memory atomic pair. Specifically, after the execution of the system under test is finished, the defect analysis module 140 uses the parameter value used in the read/write function, the ID and status of each process/thread, and the execution information of each process/thread. Defects can be analyzed using shared memory atomic pairs.

The specific defect analysis method is as follows. In the execution log collection module 130, the execution log of the read/write function may be collected and transmitted to the defect analysis module 130. Accordingly, when the read() of Thread 1 is performed in the defect analysis module 130 and the read() or write() function of Thread 2 is performed before write() is performed, the atomicity for the shared memory is It can be judged as a violation defect candidate.

On the other hand, the above-described control method of the atomic sharing violation of the process/thread control unit 150 is as follows. In this regard, in the defect analysis module 130, global variables used in the Thread 1 and the Thread 2 are used in both the first function and the second function executed by the Thread 1 and the Thread 2, and the atomicity It is possible to determine whether a candidate for a defect is violated. Accordingly, the process/thread control unit 150 may execute the write() of the thread 1 before the write() of the thread 1 is performed before the write() of the thread 1 is performed. You can control read() to be performed.

In addition, the above-described process/thread control unit 150 has a difference in that it can perform the following control scheme even when an atomic sharing violation has already occurred. In this regard, when the read() or write() function of Thread 2 is performed before the write() of Thread 1 is performed, the process/thread controller 150 may perform the following operations. At this time, the process/thread control unit 150 controls to change the global variable according to the feature changed by the write() of Thread 1, and perform read() of the Thread 2 again according to the changed global variable. can do. Therefore, even if the thread 2 is already executed and an atomic sharing violation occurs, there is an advantage that the thread 2 can be re-executed by compensating it after the thread 1 is completed.

In the above, a method and apparatus for detecting an atomic violation defect for a shared memory used in a multi-process/multi-thread according to the present invention have been described. In this regard, the technical effects of the method and apparatus for detecting an atomic violation defect for a shared memory used in a multi-process/multi-thread according to the present invention are as follows.

According to the present invention, there is an advantage in that it is possible to detect an atomic violation of the shared memory by analyzing the shared memory call that needs to be made atomistic through dictionary binary analysis and applying it to the execution data analysis obtained through hooking.

In addition, according to the present invention, it is advantageous in that a false positive rate is low because it reduces the range in which an atomic violation detection can occur through pre-analysis and analyzes based on a situation in which an actual process/thread is executed.

In addition, according to the present invention, there is an advantage in that the runtime state can be maintained as there is less overhead due to the method of detecting the test object without changing it.

The present invention can be variously changed and can have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

According to the software implementation, design and parameter optimization for each component as well as the procedures and functions described herein may be implemented as separate software modules. Software code can be implemented in a software application written in an appropriate programming language. The software code is stored in a memory and can be executed by a controller or processor.

Claims (12)

In the method of detecting atomic violation defects for shared memory used by multi-process/multi-thread,
Shared memory analysis step of pre-analyzing shared memory before process execution and extracting function pairs that need to be atomically accessed to the shared memory-the function pair is associated with the shared memory atomic pair-;
An execution log collection step of calling a function to access the analyzed shared memory and collecting execution information of each process/thread; And
And a defect analysis step of analyzing a defect using the execution information and the shared memory atomic pair. According to claim 1,
The execution log collection step,
Monitoring read/write function calls to collect execution logs accessing the shared memory with minimal impact on the execution environment,
The collected execution information includes the parameter value used in the read/write function and the ID and status of each process/thread as execution information of each process/thread. According to claim 2,
The defect analysis step,
After the execution of the system under test is finished, the defect value is analyzed by using the ID/status of each process/thread and the atomic pair of the shared memory as parameter values used in the read/write function, execution information of each process/thread Characterized in that, atomic defect detection method. According to claim 2,
In the defect analysis step,
Collect and analyze the execution log of the read/write function,
When the read() or write() function of Thread 2 is performed before the read() of Thread 1 is performed and the write() is performed, it is characterized by determining as an atomic violation defect candidate for the shared memory, Atomic Violation Defect Detection Method. According to claim 4,
When global variables used in Thread 1 and Thread 2 are used in both the first function and the second function executed by Thread 1 and Thread 2,
When the read() or write() function of Thread 2 is executed before the read() of Thread 1 is performed and the write() is performed,
A method for detecting an atomic violation defect, characterized in that in the defect analysis step, it is determined as an atomic violation defect candidate for the shared memory. According to claim 4,
When global variables used in Thread 1 and Thread 2 are used in both the first function and the second function executed by Thread 1 and Thread 2,
If the read() of the thread 2 is called before the write() of the thread 1 is executed, the multi-process that controls the read() of the thread 2 to be performed after the write() of the thread 1 is executed/ A method for detecting an atomic violation defect further comprising a multi-thread control step. The method of claim 6,
When the read() or write() function of Thread 2 is executed before the write() of Thread 1 is performed,
In the multi-process / multi-thread control step,
A method for detecting an atomic violation defect by changing the global variable according to a characteristic changed by write() of Thread 1 and controlling to read() of Thread 2 again according to the changed global variable. In the device for detecting atomic violations of shared memory used by multi-process/multi-thread,
A shared memory configured to be accessible by multi-process/multi-thread and storing variables and information;
A shared memory analysis module that pre-analyzes the shared memory and extracts a function pair that needs to be atomically accessed to the shared memory before the process is executed-the function pair is associated with a shared memory atomic pair-;
An execution log collection module that calls a function to access the analyzed shared memory and collects execution information of each process/thread; And
And a defect analysis module for analyzing defects using the execution information and the shared memory atomic pair. The method of claim 8,
The execution log collection module,
Monitoring read/write function calls to collect execution logs accessing the shared memory with minimal impact on the execution environment,
The collected execution information includes a parameter value used in the read/write function and an ID and a state of each process/thread as execution information of each process/thread. The method of claim 9,
The defect analysis module,
After the execution of the system under test is finished, the defect value is analyzed by using the ID/status of each process/thread and the atomic pair of the shared memory as parameter values used in the read/write function, execution information of each process/thread Characterized in that, the atomic violation defect detection device The method of claim 9,
In the execution log collection module,
Collect the execution log of the read/write function,
In the defect analysis module,
When the read() or write() function of Thread 2 is performed before the read() of Thread 1 is performed and the write() is performed, it is characterized by determining as an atomic violation defect candidate for the shared memory, Atomic violation defect detection device. The method of claim 11,
In the defect analysis module,
When the global variable used in the Thread 1 and the Thread 2 is used in both the first function and the second function executed by the Thread 1 and the Thread 2 and is determined as the atomic violation defect candidate,
If the read() of the Thread 2 is called before the write() of the Thread 1 is executed, the process/thread controlling to perform the read() of the Thread 2 after the write() of the Thread 1 is performed An atomic violation defect detection apparatus further comprising a control unit.

Images