Method for detecting memory access error in multithread application

Abstract

To provide a method for detecting a memory access error in a multithread application.SOLUTION: A method (100) for detecting a memory access error (8) in a multithread application includes the steps of: converting (101) the multithread application into a byte code expression (3); profiling (102) the byte code expression (3), for determining at least one shared memory access point (competing memory access) by at least two threads (4) of the byte code expression (3); inserting (103) a delay time frame to each memory access operation to the shared memory access point by at least one thread (4) of at least two threads (4); and monitoring (104) accesses of at least two threads (4) to the shared memory access point, during the delay time frame, for detecting the memory access error (8).SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a method for detecting memory access errors in multi-threaded applications, and further to a computer program, an apparatus and a storage medium for this purpose. [Background technology]

[0002] Concurrency bugs in multithreaded applications are a type of memory access error that may occur when at least two threads access and modify a memory access point of the application. These concurrency bugs, i.e., memory access errors, may be difficult to reproduce and difficult to debug because the triggering of the concurrency bug may be timing dependent. A specific order may be required for threads to execute instructions in parallel such that the application exhibits anomalous behavior. Dynamic data race detectors known in the prior art may track accesses to shared resources to observe data races, i.e., multiple accesses to a given memory access point within a significant time span.

[0003] According to a dynamic approach in the prior art, lockset analysis can be used to derive whether a pair of memory accesses share at least one mutually exclusive lock. According to another possible approach, memory accesses can be modified using special hardware support for code and data breakpoints to detect conflicting memory accesses. Other approaches have specifically explored modifying memory accesses at a larger resource granularity (e.g., class object) to do the same thing, especially with programmer annotations to minimize overhead.

[0004] The focus in the prior art has been on, inter alia, increasing instrumentation overhead, or the accuracy and / or speed of exposing data races, i.e., memory access errors, on a single machine. Edge architectures, which are becoming more and more popular in cyber-physical systems, often execute code across diverse hardware platforms with different performance characteristics that may not translate well from isolated testing. This can be commonly seen when data races, i.e., memory access errors, appear when devices are upgraded and code is moved from a single-core processor to a multi-core processor.

[0005] Due to a lack of portability, traditional solutions often rely on running on-site or simulated tests on isolated test units, which can make the process slow, inaccurate, difficult to run on heterogeneous platforms, or even technically infeasible.

[0006] Since instrumenting every raw memory access can result in high runtime overhead, most solutions try specifically to instrument at a higher level of abstraction (class objects) or to select instruction subsets to instrument. The drawback of these is that the former can provide less coverage and the latter can take a long time to detect memory access errors. Summary of the Invention [Means for solving the problem]

[0007] According to aspects of the present invention there is provided a method comprising the features of claim 1, a computer program comprising the features of claim 8, a data processing device comprising the features of claim 9 and a computer-readable storage medium comprising the features of claim 10. Further features and details of the invention are disclosed in the respective dependent claims, the description and the drawings. Features and details mentioned in the context of the inventive method also correspond to the inventive computer, the inventive data processing device and the inventive computer-readable storage medium and vice versa in each case.

[0008] According to one aspect of the present invention, a method for detecting memory access errors in a multi-threaded application includes: - converting a multi-threaded application into a bytecode representation thereof; - profiling the bytecode representation to determine at least one shared memory access point by at least two threads in the bytecode representation; - inserting a delay time frame into each memory access operation by at least one of the at least two threads to a shared memory access point; - monitoring accesses of at least two threads to a shared memory access point during a delay time frame to detect memory access errors; Includes.

[0009] The memory access error may be a data race error in which at least two threads of a bytecode representation of a multithreaded application attempt to modify a given memory access point during a critical time frame. This may result in unintended anomalous behavior in a multithreaded application. Therefore, detecting memory access errors by the method according to the present invention may be advantageous in preventing such unintended anomalous behavior due to memory access errors. The use of a bytecode representation may be advantageous in that it can be easily scaled across heterogeneous devices and can provide low execution and memory overhead. The memory access point may be a variable used by both of the at least two threads. The delay time frame may be defined according to a specific use case or may be determined by trial and error. The monitoring of the access during the delay time frame may begin after one of the at least two threads accesses the shared memory access point. In other words, the monitoring may suggest that after a first access by a thread, it is verified whether another access by another thread occurs during the delay time frame. In this case, it may be concluded that the other access may cause a memory access error. Furthermore, it may be specified that the monitoring of the access applies only to accesses that modify the shared memory access point. The delay time frame can be changed at least once, in particular at least twice. After changing the delay time frame, the access monitoring can be performed again accordingly in order to detect memory access errors based on at least two different delay time frames. Thus, the bytecode representation can be executed at least twice in each delay time frame and the access monitoring can be performed at least twice accordingly, advantageously in order to detect memory access errors based on at least two different delay time frames.

[0010] Profiling is - performing a static analysis of the source code in a bytecode representation to determine at least one shared memory access point; It is possible to include:

[0011] Static analysis can be advantageous in that the entire source code can be analyzed, so any memory access point can be taken into account. In addition, profiling - modifying the byte-code representation to log memory accesses during execution of the byte-code representation; - identifying each of the memory access points as at least one shared memory access point if the respective memory access point is accessed by at least two different threads of the bytecode representation during execution; It is possible to include:

[0012] The modification may in particular be instrumentation of the bytecode representation. Instrumentation of the bytecode representation may refer to adding additional code that may enable logging of memory accesses during execution of the bytecode representation. The two steps mentioned above in this specification may also be referred to as dynamic analysis. Dynamic analysis may be advantageous in that it may take less time to perform compared to analysis of the entire source code. Furthermore, profiling the bytecode representation during execution may advantageously detect additional memory access errors that could not be detected by static analysis.

[0013] In another example, at least during the monitoring of accesses, the bytecode representation is executed on at least two different devices, the at least two different devices differing from each other with respect to at least one performance characteristic. Execution of the bytecode representation on at least two different devices may be advantageous in that characteristics of the different devices may be exposed, thereby increasing or decreasing the likelihood that a memory access error will appear. Furthermore, using two different devices instead of a single device advantageously improves the performance of detecting memory access errors. The at least one performance characteristic may be processing power or network performance. In the context of the present invention, the device may be a processing node. It is also possible that the bytecode representation is divided into subsets of bytecode instructions, and the subsets of bytecode instructions are profiled separately across the at least two different devices.

[0014] The modification of the bytecode representation may be performed according to at least one performance characteristic of each of the at least two different devices, which may be advantageous in that time-critical applications are not unduly impaired by the additional instrumentation.

[0015] In another example, profiling - sampling at least a random subset of instructions of the bytecode representation; - executing the bytecode representation based on the sampled at least one random instruction subset; Further includes:

[0016] This may be advantageous in that only a smaller number of instructions need to be profiled compared to the entire multi-threaded application, which may improve performance of the method. It may be advantageous to run each random subset on each device. The random subsets may be different across the various devices that may be used.

[0017] In another example, the method includes: - eliminating at least one memory access operation, and in particular all memory access operations, of the bytecode representation that do not access the at least one determined shared memory access point; Further includes:

[0018] The term pruning may refer to the respective memory access operation being removed or ignored and therefore not executed by the bytecode representation, which may be advantageous in that fewer instructions may need to be executed to profile the bytecode representation and / or to detect memory access errors, reducing the required processing power.

[0019] This method is - Steps to initiate an alert if a memory access error is detected It may further include:

[0020] The alert may be advantageous in that the user is notified so that the user can initiate appropriate measures in response. In another aspect of the invention, a computer program, in particular a computer program product, may be provided comprising instructions which, when said computer program is executed by a computer, cause said computer to carry out the method according to the invention. The computer program according to the invention may therefore have the same advantages as those detailed with reference to the method according to the invention.

[0021] In another aspect of the invention, a data processing apparatus may be provided, configured to carry out the method according to the invention. As the apparatus, for example, a computer may be provided which executes the computer program according to the invention. The computer may include at least one processor which can be used to execute the computer program. Also, a non-volatile data memory may be provided in which the computer program may be stored and from which the computer program may be read and executed by the processor.

[0022] According to another aspect of the invention, a computer-readable storage medium may be provided that includes a computer program according to the invention and / or instructions that, when executed by a computer, cause the computer to carry out the steps of the method according to the invention. The storage medium may be formed as a data storage device such as a hard disk, and / or a non-volatile memory, and / or a memory card, and / or a solid-state drive. The storage medium may for example be integrated into the computer.

[0023] Additionally, methods in accordance with the present invention may be implemented as computer-implemented methods. Further advantages, features and details of the invention will become apparent from the following description, in which embodiments of the invention are described in detail with reference to the drawings. In this context, the features mentioned in the claims and in this specification may be essential to the invention, each individually or in any combination. [Brief description of the drawings]

[0024] [Figure 1] 1 illustrates a method, a computer program, a storage medium, and an apparatus according to an embodiment of the present invention. [Diagram 2] FIG. 2 illustrates an architecture for a framework for detecting memory access errors according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] FIG. 1 shows a method 100, a computer program 20, a storage medium 15 and an apparatus 10 according to an embodiment of the invention. A method 100 for detecting memory access errors 8 in a multi-threaded application according to the embodiment shown in FIG. 1 comprises the following steps: In a first step 101, a multi-threaded application is converted into its bytecode representation 3. In a second step 102, the bytecode representation 3 is profiled to determine at least one shared memory access point by at least two threads 4 in the bytecode representation 3. In a third step 103, a delay time frame is inserted into each memory access operation to the shared memory access point by at least one thread 4 of the at least two threads 4. In a fourth step 104, during the delay time frame, accesses of the at least two threads 4 to the shared memory access point are monitored to detect memory access errors 8.

[0026] Figure 2 shows an architecture 1 for a framework for detecting memory access errors 8 according to an embodiment of the invention. On the left side of Figure 2, a profiling step 102 according to one embodiment is shown. A bytecode representation 3 may be input to a batch balance instrument 2. Furthermore, multiple threads 4 of an application may be executed on different devices 5 in order to detect conflicting memory accesses 6, i.e. shared memory access points. The conflicting memory accesses 6 and the bytecode representation 3 may then be input to a batch probabilistic instrument 7 in order to perform a detection step 103 according to one embodiment. Again, multiple threads 4 may be executed on different devices 5 and then memory access errors 8 may be detected.

[0027] According to an embodiment of the present invention, an intermediate code representation (IR), i.e., bytecode representation 3, preferably WebAssembly, is used. As a language- and platform-independent compilation target, the intermediate code representation, preferably WebAssembly, can be easily scaled across heterogeneous devices and can provide very low execution and memory overhead. The use of WebAssembly as an intermediate code representation, i.e., bytecode representation 3, allows for easy instrumentation by enabling a condensed and portable instruction set to work.

[0028] This approach can also be applied to any number of bytecode-based virtual execution environments, such as Java, WebAssembly, LUA, Python, etc. WebAssembly may be preferred because it supports many different programming languages, can execute at near-native speed, and its semantics may be formally defined to eliminate non-deterministic execution, making this process even more efficient.

[0029] One insight of the method according to the embodiment of the present invention may be that increased timing variability may be prone to generate more memory access errors 8. That is, probing all possible memory access points in the code may not necessarily be optimal to find memory access errors 8, since the probing itself may limit the scope of timing variability. Two approaches that can investigate the timing characteristics of multi-threaded applications are described herein below: platform heterogeneity and probabilistic instrumentation. The combination of these two may also enable fine-grained memory access tracking without incurring the same overhead as the previously mentioned approaches.

[0030] By running a wide range of heterogeneous devices 5 in parallel, more memory access errors 8, i.e. data races, can be detected more quickly than when running a single device 5. This may also expose characteristics of the device 5 that make such bugs, i.e. memory access errors, more likely to appear. Furthermore, for timing-critical applications that require performance thresholds for functional correctness, the portability and amount of instrumentation can be tailored to match the performance characteristics of the device 5. Faster devices 5 can be instrumented more, while slower devices, such as resource-limited microcontrollers, which are often difficult to profile and debug, may exercise a subset of targeted instrumentation points.

[0031] Memory access, or data race, errors8 can be effectively detected by methods according to embodiments of the invention by scaling out the detection process using a bytecode representation3, preferably WebAssembly, as the base format. Instrumentation of WebAssembly binaries may be used, allowing the approach to work with Ahead of Time (AoT), Interpreted, or Just-in-Time (JIT) execution layers across multiple platforms.

[0032] A method according to an embodiment of the invention may include two phases: a profiling phase may be used to enable pruning of irrelevant memory accesses that cannot cause data races, and a violation detection phase may be used to detect concurrent accesses to memory locations.

[0033] Since the method according to the embodiments of the present invention works at the abstract level of the bytecode representation, it can be assumed that source code from any supported language can be compiled into a multithreaded application, and in particular into a WebAssembly module.

[0034] Typically, a certain number of memory accesses may not cause race conditions, such as race conditions for thread-local variables and unreferenced function locals on the stack. It may be advantageous to prune these out to reduce overhead when performing violation detection. Due to runtime function pointers and pointer aliasing, offline methods of doing this may be ineffective, even for programs with static memory allocation. Runtime profiling may be performed by instrumenting the code to call a custom WebAssembly host function for every memory access operation and logging accesses to memory regions as they occur. If an access from at least two different thread IDs is observed, the address may be marked as a conflicting memory access6, indicating a possible conflict. Once profiling is completed for a certain period of time, a reduced subset of memory accesses may be provided to instrument for the next phase. This analysis may be rather slow, especially when simply performed on a single device5. Hence, map-reduce techniques may be employed to speed it up. One approach may be to sample a random instruction subset, profile the subset in parallel on a distributed cluster of devices 5, and take the union of all the parts. This method may also work when there is non-deterministic malloc and thread creation in the code, but may require large scale-out for good coverage, since a given pair sampled together may be required in at least one instance. However, for deterministic programs, the memory determinism of the bytecode representation, and in particular that of WebAssembly, can be leveraged to ensure that a given instruction accesses the same memory address, i.e., memory access point, across all executions on any device 5. As a result, separate sets may be instrumented in parallel, and merging may be performed under the assumption that memory accesses and thread IDs are consistent across devices 5.Furthermore, to improve the average overhead, not only random isolation partitions but also "balanced execution partitions" may be observed, where each device 5 receives an equal number of instrumentation points at every block / loop scope. This prevents one device 5 from executing a heavily instrumented hot loop and disrupting the algorithm. This can also be performed across heterogeneous devices 5 for wider code coverage.

[0035] After getting the conflicting memory accesses, only those accesses can be instrumented for memory access error 8, i.e. data race detection phase. In the instrumented code, an algorithm may be assumed where a trap is set, a delay is inserted in the instrumentation, and the trap is cleared. If during this delay another access occurs at this address, i.e. memory access point, and either access is a write, a violation, i.e. memory access error 8, may be detected and the pair of accesses may be logged.

[0036] One different approach may be to start by assuming that every instrumentation point may cause a memory access error 8. This may result in a higher probability of capturing infrequent code paths. A previous profiling step may have already pruned safe accesses, making this step unnecessary. Assuming this algorithm, more memory access errors 8 may be detected by increasing the timing variability. A map-reduce approach similar to that described above may be performed. Thus, a probabilistic subset of these memory access points may be instrumented, and detection of memory access errors 8 may be performed in parallel on the distributed devices 5. The detected violations, i.e., memory access errors 8, from each device 5 may finally be merged and deduplicated to generate a final set of violations, i.e., memory access errors 8, across the cluster.

[0037] The above description of the embodiments is given by way of example only, and the present invention can of course be freely combined with the individual features of the embodiments, provided that it is technically reasonable, without departing from the scope of the present invention. [Explanation of symbols]

[0038] 3 Bytecode Representation 4 Threads 5 Devices 8 Memory Access Error 10. Computers 15 Computer-readable storage medium 20 Computer Programs 100 ways

Claims

1. A method (100) for detecting memory access errors (8) in a multi-threaded application, comprising: A step (101) of converting said multi-threaded application into its bytecode representation (3); profiling (102) said bytecode representation (3) to determine at least one shared memory access point by at least two threads (4) of said bytecode representation (3); inserting (103) a delay time frame into each memory access operation to said shared memory access point by at least one thread (4) of said at least two threads (4); monitoring (104) accesses of said at least two threads (4) to said shared memory access point during said delay time frame to detect said memory access errors (8); The method (100) comprising:

2. The profiling (102) performing a static analysis of the source code of said bytecode representation (3) to determine said at least one shared memory access point.

2. The method (100) of claim 1, comprising:

3. The profiling (102) modifying the bytecode representation (3) to log memory accesses during execution of the bytecode representation (3); identifying each of the memory access points as the at least one shared memory access point if the respective memory access point is accessed by at least two different threads (4) of the bytecode representation (3) during the execution; 3. The method (100) of claim 1 or 2, comprising:

4. The method (100) according to any one of claims 1 to 3, characterized in that, at least during said monitoring (104), said bytecode representation (3) is executed on at least two different devices (5), said at least two different devices (5) differing from each other with respect to at least one performance characteristic.

5. 5. The method (100) according to claim 3 or 4, characterized in that the modification of the bytecode representation (3) is performed according to the at least one performance characteristic of each of the at least two different devices (5).

6. The profiling (102) Sampling at least a random subset of instructions of said bytecode representation (3); Executing the bytecode representation (3) based on the sampled at least one random instruction subset; The method (100) according to any one of claims 3 to 5, further comprising:

7. eliminating at least one memory access operation, in particular all memory access operations, of said bytecode representation (3) that do not access said at least one determined shared memory access point; The method (100) according to any one of claims 1 to 6, further comprising:

8. When the computer program (20) is executed by the computer (10), the computer (10) A computer program (20) comprising instructions for carrying out the method (100) of any one of claims 1 to 7.

9. A data processing apparatus (10) comprising means for performing the method (100) according to any one of the preceding claims.

10. When executed by a computer (10), the computer (10) A computer readable storage medium (15) comprising instructions for carrying out the steps of the method (100) of any one of claims 1 to 7.

Images