CH713111A2

CH713111A2 - Static detection of concurrency errors in computer programs.

Info

Publication number: CH713111A2
Application number: CH01474/16A
Authority: CH
Inventors: Bläser Luc
Original assignee: Luc Blaeser Hochschule Fuer Technik Rapperswil
Priority date: 2016-11-07
Filing date: 2016-11-07
Publication date: 2018-05-15

Abstract

Die Erfindung betrifft eine Methode für die schnelle und hochpräzise statische Erkennung von Nebenläufigkeitsfehlern in Computerprogrammen wie z.B. Data Races, Deadlocks oder Thread-unsichere API-Verwendung. Die Methode umfasst vier Hauptschritte (100). Erfindungsgemäss wird wiederholt die nebenläufige Programmausführung auf einem internen isolierten Laufzeitmodell mit zufälliger Ablaufplanung und einstellbaren Schranken simuliert. Es unterhält genaue Programmzustände mit Ausnahme für unbekannte externe Eingaben und unvollständige Programmteile. Nebenläufigkeitsfehler, die auf dem internen Modell geschehen, werden erkannt und als Fehler gemeldet. Dieser Mechanismus erkennt viele Nebenläufigkeitsfehler mit beinahe keinen False Positives in der kurzen Zeit von ein paar Sekunden.The invention relates to a method for the fast and high-precision static detection of concurrency errors in computer programs such as e.g. Data Races, deadlocks, or thread-insecure API usage. The method comprises four main steps (100). According to the invention, the concurrent program execution is repeatedly simulated on an internal isolated runtime model with random scheduling and adjustable barriers. It maintains exact program states except for unknown external inputs and incomplete program parts. Concurrency errors that occur on the internal model are detected and reported as errors. This mechanism detects many concurrency errors with almost no false positives in the short time of a few seconds.

Description

Beschreibungdescription

Technisches Gebiet [0001] Fehlererkennung durch Korrektheitsprüfung der Ausführungsreihenfolge (WIPO Klassifikation G06F 11/28).Technical field Error detection by correctness check of the execution order (WIPO classification G06F 11/28).

Hintergrund und Stand der Technik [0002] Nebenläufigkeitsfehler sind häufige Programmierdefekte in Computerprogrammen, die aufgrund der parallelen oder verzahnten Ausführung von mehreren Threads oder Prozessen nichtdeterministisch auftreten. Mögliche Arten von Nebenläufigkeitsfehler sind Race Conditions, Data Races, Deadlocks und andere.Background and prior art Concurrency errors are common programming defects in computer programs that occur non-deterministically due to the parallel or interlocked execution of multiple threads or processes. Possible types of concurrency errors are race conditions, data races, deadlocks and others.

[0003] Race Conditions bezeichnen inkorrektes Programmverhalten wegen nebenläufiger Ausführung von ungenügend synchronisierten Programmabschnitten. Race Conditions können im Allgemeinen nicht formalisiert werden, weil sie von der Programmsemantik der kritischen Abschnitte abhängen, d.h. Abschnitte, die höchstens durch einen Thread zu einer Zeit ausgeführt werden dürfen. In bestimmten Fällen jedoch können nebenläufige Aufrufe oder Zugriffe auf ein als nicht Thread-sicher spezifiziertes Application Programming Interface (API) als potentielle Race Conditions betrachtet werden.Race conditions refer to incorrect program behavior due to concurrent execution of insufficiently synchronized program sections. Race conditions generally cannot be formalized because they depend on the program semantics of the critical sections, i.e. Sections that can only be executed by one thread at a time. In certain cases, however, concurrent calls or access to an application programming interface (API) that is not specified as thread-safe can be considered as potential race conditions.

[0004] Data Races bezeichnen nicht-synchronisierte nebenläufige Zugriffe auf gemeinsame Speicherorte mit mindestens einem schreibenden Zugriff, z.B. auf dieselbe Variablen oder Array-Elemente. Zugriffe gelten als synchronisiert, wenn sie mit einer gemeinsamen gegenseitig ausschliessenden Sperre geschehen. In bestimmtem Sprachen wie z.B. C# oder Java werden zudem Zugriffe auf volatile Variablen oder Paare von atomaren Zugriffen als synchronisiert betrachtet. Data Races stellen formale Programmierfehler dar, bei denen die sichtbare Ausführungsreihenfolge zwischen den Threads gemäss Programmiersprache Undefiniert ist. Im Falle von Data Races sind häufig auch Race Conditions involviert. Deshalb ist deren Erkennung von besonderem Interesse.Data races refer to unsynchronized concurrent access to shared storage locations with at least one write access, e.g. to the same variable or array elements. Accesses are considered to be synchronized if they occur with a shared mutually exclusive lock. In certain languages such as C # or Java are also viewed as accesses to volatile variables or pairs of atomic accesses as synchronized. Data races are formal programming errors in which the visible order of execution between the threads is undefined according to the programming language. In the case of data races, race conditions are often also involved. Therefore, their detection is of particular interest.

[0005] Deadlocks bezeichnen Situationen, in denen sich mehrere Threads gegenseitig zyklisch auf ewig blockieren. Dies geschieht, indem jeder involvierte Thread bereits eine Sperre (oder mehrere Sperren) hält und zudem auf eine weitere Sperre von einem anderen Thread in einer zyklischen Art und Weise wartet.Deadlocks refer to situations in which several threads block each other cyclically forever. This is done by each thread involved already holding a lock (or several locks) and also waiting for another lock from another thread in a cyclical manner.

[0006] Im Allgemeinen gibt es zwei Kategorien von Werkzeugen, die solche Nebenläufigkeitsfehler erkennen können: Statische Analyse und dynamische Analyse. Eine statische Analyse operiert auf dem Quellcode oder dem kompilierten Code eines Programms, ohne dass es diesen ausführt [Ster93, PG03b, EA03, NAW06, PFH06, P1, P2, P4, P5, P7, P8, P10, P17, P18, P19, P20, P23, P26, P30, P33j. Eine dynamische Analyse beobachtet ein laufendes Programm, ob die effektive Ausführung irgendwelche Fehler verursacht [Me91, SBN+97, PG03a, SI09, MMN09, FF09, XXII, P3, P4, P6, P9, P11, P12, P13, P14, P15, P16, P20, P21, P22, P24, P27, P28, P29, P31, P32, P34, P36; P37, P38, P39, P40, P41j.[0006] In general, there are two categories of tools that can detect such concurrency errors: static analysis and dynamic analysis. A static analysis operates on the source code or the compiled code of a program without it executing it [Ster93, PG03b, EA03, NAW06, PFH06, P1, P2, P4, P5, P7, P8, P10, P17, P18, P19, P20, P23, P26, P30, P33j. A dynamic analysis observes a running program whether the effective execution causes any errors [Me91, SBN + 97, PG03a, SI09, MMN09, FF09, XXII, P3, P4, P6, P9, P11, P12, P13, P14, P15, P16, P20, P21, P22, P24, P27, P28, P29, P31, P32, P34, P36; P37, P38, P39, P40, P41j.

[0007] Viele statische Prüfwerkzeuge (Checker) sind vollständig (auch «sound» genannt), d.h. finden alle potentielle Fehler, jedoch mit möglichen False Positives, d.h. Meldungen, die keine echten Fehler darstellen. Techniken wie [Ster93, PG03b, EA03, NAW06, PFH06, KYS+07, HOG14, P1, P2, P5, P7, P8, P10, P18, P19, P20, P23] haben keine präzise Analyse in Bezug auf die Frage, welche Programmteile zueinander nebenläufig ausgeführt werden. Dies würde nämlich eine Analyse der gegenseitigen Thread Start/Join Abhängigkeiten erfordern, um diejenigen Codeteile zu identifizieren, die möglicherweise direkt oder indirekt nebenläufig sind bzw. sicherlich nicht nebenläufig sind. Zudem fehlt oft auch die Information über sog. Aliases oder eine entsprechende Aussage ist nur ungenau. Andere statische Methoden verfügen über eine detailliertere Analyse, welche die Fork/Join-Beziehungen berücksichtigt [PG03b, P26] oder Pointer Aliasing bestimmt [P20, P26j. Dies hilft, die Anzahl False Positives zu reduzieren, während die Analyse jedoch konservativ bleibt. Constraint Solver [P17] und Model Checker [JPF, P4, P30] sind in der Lage, einen genaueren Kontext zu berechnen. Diese Methoden leiden jedoch am Problem der exponentiellen Zustandsexplosion, welche typischerweise die Anwendung auf grössere Programme verunmöglicht. Abgesehen von der exponentiellen Zustandsexplosion erfordert die Concrete Interpretation [JPF] ein vollständig interpretierbares Programm ohne externen Input/Output. Abstract Interpretation [KPP12] kann den Zustandsraum zwar verringern, aber der Analyseaufwand nimmt dennoch im Allgemeinen exponentiell zu. Des Weiteren existiert ein Ansatz, der statisch berechnete Zufallsverzahnungen innerhalb von nebenläufigen Programmen auf ein sequentielles Programm abbildet, sodass schliesslich letzteres geprüft wird [P33j. Die hier beschriebene Erfindung benötigt hingegen keine vorangehende Abbildung in ein sequentielles Programm vor der Analyse, sondern sie benutzt eine direkte Simulation des interpretierten Programms.Many static test tools (checkers) are complete (also called "sound"), i.e. find all potential errors, but with possible false positives, i.e. Messages that are not real errors. Techniques such as [Ster93, PG03b, EA03, NAW06, PFH06, KYS + 07, HOG14, P1, P2, P5, P7, P8, P10, P18, P19, P20, P23] have no precise analysis regarding which question Program parts are executed concurrently. This would require an analysis of the mutual thread start / join dependencies in order to identify those parts of the code that may or may not be concurrently directly or indirectly. In addition, information about so-called aliases is often missing or a corresponding statement is only inaccurate. Other static methods have a more detailed analysis that takes the fork / join relationships into account [PG03b, P26] or determines pointer aliasing [P20, P26j. This helps reduce the number of false positives, but the analysis remains conservative. Constraint Solver [P17] and Model Checker [JPF, P4, P30] are able to calculate a more precise context. However, these methods suffer from the problem of exponential state explosion, which typically makes it impossible to apply them to larger programs. Apart from the exponential state explosion, the Concrete Interpretation [JPF] requires a fully interpretable program without external input / output. Abstract Interpretation [KPP12] can reduce the state space, but the analysis effort generally increases exponentially. There is also an approach that maps statically calculated random gears within concurrent programs to a sequential program, so that the latter is finally checked [P33j. The invention described here, on the other hand, does not require a previous mapping into a sequential program before the analysis, but rather uses a direct simulation of the interpreted program.

[0008] Einige statische Checker geben die Vollständigkeit (Soundness) zugunsten einer höheren Genauigkeit (weniger False Positives) und einer schnelleren Analysegeschwindigkeit auf [P4, P5j. Bounded Model Checking [CB+01] beschränkt die Analysetiefe, aber bewirkt immer noch eine exponentielle Zustandsexplosion. Der aktuelle Stand der Technik auf dem Gebiet der Random Interpretation [Gul05, GN05, CM12] in der statischen Analyse behandelt die Nebenläufigkeitsanalyse noch nicht genügend.Some static checkers give up the completeness (soundness) in favor of a higher accuracy (fewer false positives) and a faster analysis speed [P4, P5j. Bounded Model Checking [CB + 01] limits the depth of analysis, but still causes an exponential state explosion. The current state of the art in the field of random interpretation [Gul05, GN05, CM12] in the static analysis does not sufficiently deal with the concurrency analysis.

[0009] Dynamische Checker sind zwar typischerweise genau (keine False Positives), dafür aber unvollständig («unsound», mit False Negatives). Diese benötigen ein vollständiges und laufendes Programm [Me91, SBN+97, PG03a, SI09, MMN09, FF09, XX11, P3, P4, P6, P9, P11, P12, P13, P14, P15, P16, P20, P21, P22, P24, P27, P28, P29, P31, P32, P34, P36, P37, P38, P39, P40, P41 ]. Dies ist allerdings oft impraktikabel, weil viele getestete Programme Input/OutputInteraktionen erfordern. Einige dynamische Checker verwenden wiederum intern eine statische Analyse [P16, P24, P38] oder eine zufällige Ablaufplanung [P14, P27, P32, P36, P41], um die Programmabdeckung zu erhöhen und damit die False Negatives zu verringern. Ein dynamischer Checker, welche alle relevanten Ablaufpläne (Schedules) abprüft [MQB07, P38], leidet wiederum am exponentiellen Suchraum. Im Gegensatz zu den erwähnten dynamischen Checker ist diese Erfindung eine statische Methode, d.h. sie analysiert nicht-laufenden Programmcode und kann auch mit unvollständigem Programmcode umgehen.Dynamic checkers are typically accurate (no false positives), but are incomplete ("unsound", with false negatives). These require a complete and ongoing program [Me91, SBN + 97, PG03a, SI09, MMN09, FF09, XX11, P3, P4, P6, P9, P11, P12, P13, P14, P15, P16, P20, P21, P22, P24, P27, P28, P29, P31, P32, P34, P36, P37, P38, P39, P40, P41]. However, this is often impractical because many tested programs require input / output interactions. Some dynamic checkers use static analysis [P16, P24, P38] or random scheduling [P14, P27, P32, P36, P41] internally to increase the program coverage and thus reduce the false negatives. A dynamic checker, which checks all relevant schedules [MQB07, P38], again suffers from the exponential search space. In contrast to the dynamic checkers mentioned, this invention is a static method, i.e. it analyzes non-running program code and can also deal with incomplete program code.

[0010] Es ist keine existierende Methode bekannt, welche auf statische Weise Nebenläufigkeitsfehler mittels beschränkter weitgehend konkreter Interpretation mit zufälliger Thread-Ablaufplanung erkennt.No existing method is known which recognizes concurrency errors in a static manner by means of limited largely concrete interpretation with random thread scheduling.

Darstellung der Erfindung [0011] Ein Mechanismus für die schnelle und hochpräzise statische Erkennung von Nebenläufigkeitsfehlern in Computerprogrammen, wie z.B. Data Races, Deadlocks oder Thread-unsichere API-Verwendung. Der Mechanismus simuliert wiederholt die nebenläufige Programmausführung auf einem internen isolierten Laufzeitmodell mit zufälliger Ablaufplanung und einstellbaren Schranken. Es unterhält genaue Programmzustände mit Ausnahme für unbekannte externe Eingaben und unvollständige Programmteile. Nebenläufigkeitsfehler, die auf dem internen Modell geschehen, werden erkannt und als Fehler gemeldet. Versuche haben gezeigt, dass dieser Mechanismus anderen existierenden Prüfwerkzeugen insofern überlegen ist, als dass er viele Nebenläufigkeitsfehler mit beinahe keinen False Positives in der kurzen Zeit von ein paar Sekunden erkennt.Representation of the invention A mechanism for the fast and high-precision static detection of concurrency errors in computer programs, e.g. Data races, deadlocks, or thread-insecure API usage. The mechanism repeatedly simulates concurrent program execution on an internal isolated runtime model with random scheduling and adjustable barriers. It maintains exact program states with the exception of unknown external inputs and incomplete program parts. Concurrency errors that occur on the internal model are recognized and reported as errors. Tests have shown that this mechanism is superior to other existing test tools in that it detects many concurrency errors with almost no false positives in the short time of a few seconds.

Aufzählung der Zeichnungen [0012] Die Zeichnungen dienen der Erklärung der Erfindungsbeschreibung.List of the drawings The drawings serve to explain the description of the invention.

[0013] Abbildung 1 zeigt ein Sequenzdiagramm 100 für die Hauptschritte des Prüfmechanismus. Schritt 2104 und Schritt 3106 werden bedingt wiederholt, so wie es in Schritt 3106 definiert ist.Figure 1 shows a sequence diagram 100 for the main steps of the testing mechanism. Step 2104 and step 3106 are conditionally repeated as defined in step 3106.

[0014] Abbildung 2 zeigt ein Klassendiagramm 200 des Hauptteils des internen Laufzeitmodels, so wie es in der Simulation verwendet wird. Pfeile mit einem Stern bezeichnen eins-zu-mehrere Beziehungen. Das Model stellt einen Programmzustand 202 dar, welches eine Menge von lauffähigen Threads 204 umfasst. Jeder Thread 206 verfügt über einen Stack 212 seiner aktivierten Prozeduren 214 mit den lokalen Variablen 218232 (inkl. Parametern) sowie seiner aktiven Instruktion 216. Letztere ist ein Knoten im Kontrollflussgraphen (Control Flow Graph, CFG) 220. Zudem verfügt das Model über einen Heap 224 mit Objekten 226, welche ihre Objektvariablen 228 enthalten. Zusätzlich gibt es statische und globale Variablen 230.Figure 2 shows a class diagram 200 of the main part of the internal runtime model, as used in the simulation. Arrows with an asterisk indicate one-to-several relationships. The model represents a program state 202, which comprises a set of executable threads 204. Each thread 206 has a stack 212 of its activated procedures 214 with the local variables 218232 (including parameters) and its active instruction 216. The latter is a node in the control flow graph (CFG) 220. The model also has a heap 224 with objects 226, which contain their object variables 228. There are also static and global variables 230.

[0015] Abbildung 3 erklärt die Vektorzeit für die Bestimmung der «Happens-Before» Beziehungen [Lam78] 300. Die Zeit ist in dem Beispiel ein Vektor mit drei Komponenten. Bei Thread T1 302 bezeichnet die erste Komponente seine eigene lokale logische Zeit, während die anderen zwei Komponenten die Zeit angeben, zu welcher sich T1 zum letzten Mal mit T2 resp. T3 synchronisiert hat. Das Analoge gilt für T2304 und T3306. In jedem Zeitschritt auf der vertikalen Achse 308310 312 schreitet die eigene Zeitkomponente um eins voran. Querpfeile 316320 bezeichnen Synchronisationen zwischen Threads: T1 synchronisiert sich mit T2316 und T2 sich mit T3320. Der sich synchronisierende Thread 314 nimmt dabei für jede Zeitkomponente das Maximum von seiner eigenen Zeitkomponente und der entsprechenden Komponente vom synchronisierten Thread an 318. Eine Zeit X 322 wird «Happens-Before» Y genannt 318314, sofern alle Zeitkomponenten von X kleiner oder gleich der entsprechenden Komponente von Y sind, wobei mindestens eine Zeitkomponente von X effektiv kleiner als die entsprechende von Y sein muss.Figure 3 explains the vector time for the determination of the happens-before relationships [Lam78] 300. The time in the example is a vector with three components. In thread T1 302, the first component designates its own local logical time, while the other two components indicate the time at which T1 last changed to T2 or T3 has synchronized. The same applies to T2304 and T3306. In each time step on the vertical axis 308310 312, the own time component advances by one. Cross arrows 316320 indicate synchronizations between threads: T1 synchronizes with T2316 and T2 synchronizes with T3320. The synchronizing thread 314 assumes for each time component the maximum of its own time component and the corresponding component from the synchronized thread 318. A time X 322 is called “Happens-Before” Y 318314, provided that all time components of X are less than or equal to the corresponding one Are components of Y, whereby at least one time component of X must be effectively smaller than the corresponding one of Y.

[0016] Abbildung 4 zeigt das Klassendiagramm 400, welches das interne Laufzeitmodell um den zugehörigen Vektorzeiten 412416 426 und die Sperrinformationen bei Synchronisationsobjekte 418420 426 ergänzt.Figure 4 shows the class diagram 400, which supplements the internal runtime model with the associated vector times 412416 426 and the locking information for synchronization objects 418420 426.

[0017] Abbildung 5 zeigt das Sequenzdiagramm 500 für die Unterschritte in Schritt 3106.Figure 5 shows the sequence diagram 500 for the substeps in step 3106.

Ausführung der Erfindung [0018] Der Mechanismus erkennt auf statische Weise potentielle Nebenläufigkeitsfehler, wie z.B. Data Races, Deadlocks oder Thread-unsichere Verwendung von APIs. Der Mechanismus besteht aus vier Hauptschritten (Abbildung 1) 100.Implementation of the Invention The mechanism statically detects potential concurrency errors, e.g. Data races, deadlocks or thread-insecure use of APIs. The mechanism consists of four main steps (Figure 1) 100.

Schritt 1: Modellvorbereitung [0019] Der Quellcode oder der kompilierte Code eines Programms wird mit üblichen Compilertechniken analysiert, so dass ein Kontrollflussgraph (Control Flow Graph, CFG) für jede Prozedur (Methode, Konstruktor, Property, Indexer, Operator etc.) erzeugt wird. Jeder Knoten im Kontrollflussgraphen stellt dabei eine einzelne Instruktion in einer Prozedur dar (z.B. das Lesen einer Variable, das Schreiben einer Variable, das Laden einer Konstante etc.).Step 1: Model preparation The source code or the compiled code of a program is analyzed using conventional compiler techniques, so that a control flow graph (CFG) is generated for each procedure (method, constructor, property, indexer, operator etc.) , Each node in the control flow graph represents a single instruction in a procedure (e.g. reading a variable, writing a variable, loading a constant, etc.).

[0020] Eine Eingabe oder ein Resultat, welche von nicht analysierten externen Aufrufen oder fehlendem Programmcode stammt, wird dabei als spezieller «uninterpretierter» (nicht interpretierter) Wert dargestellt. Dieser spezielle Wert steht für jeden möglichen Wert, welcher in der Analyse unbekannt ist.An input or a result that comes from non-analyzed external calls or missing program code is shown as a special “uninterpreted” (uninterpreted) value. This special value stands for every possible value which is unknown in the analysis.

[0021] Es wird ein initiales Laufzeitmodel 200 vorbereit, welches den gesamten simulierten Programmzustand repräsentiert, so wie er in einem echten Laufzeitsystem existiert (Abbildung 2). Thread Pool Tasks können im Modell als Threads repräsentiert werden, sofern sie keinen zugewiesenen Dispatcher (wie z.B. in C#) haben. Tasks mit Dispatcher können als Prozeduren des entsprechenden Dispatcher Thread abgebildet werden, wobei der Dispatcher Thread die registrierten Prozeduren seriell ausführt.An initial runtime model 200 is prepared, which represents the entire simulated program state, as it exists in a real runtime system (Figure 2). Thread pool tasks can be represented as threads in the model, provided they do not have an assigned dispatcher (such as in C #). Tasks with dispatchers can be mapped as procedures of the corresponding dispatcher thread, the dispatcher thread executing the registered procedures serially.

[0022] Eine Vektorzeit [Lam78] wird eingesetzt, um die «Happens-Before»-Beziehungen zwischen den ausgeführten Instruktionen der Threads darzustellen 300. Diese Information wird für die Bestimmung von Data Races oder Thread-unsicherer API-Verwendung benötigt. Jeder Thread 206402 trägt seine Vektorzeit 414416 innerhalb des Models 200400. Die Zeit definiert seine eigene logische Zeit sowie die Zeitpunkte, zu welchen sich der Thread zum letzten Mal mit den anderen Threads synchronisiert hat (Abbildung 3) 300.A vector time [Lam78] is used to represent the “happens-before” relationships between the executed instructions of the threads 300. This information is required for the determination of data races or thread-insecure API use. Each thread 206402 carries its vector time 414416 within the model 200400. The time defines its own logical time as well as the times at which the thread last synchronized with the other threads (Figure 3) 300.

[0023] Jeder Thread zeichnet alle seine durchgeführten Zugriffe auf 404. Jeder Zugriff 406 wird mit dem Zeitpunkt 412 und dem Ziel (Variable, Array Element oder API Zugriff/Aufruf) gemerkt. Zudem wird auch festgehalten, ob der Zugriff synchronisiert ist (z.B. atomarer Zugriff oder Zugriff auf eine volatile Variable in Java oder C#).Each thread records all of its accesses made to 404. Each access 406 is noted with the time 412 and the destination (variable, array element or API access / call). It also records whether the access is synchronized (e.g. atomic access or access to a volatile variable in Java or C #).

[0024] Objekte 226420, welche der Synchronisation dienen (z.B. Monitore, Semaphore, Read-Write Looks etc.) tragen zudem Informationen zur Sperre, d.h. die Angabe des Sperrinhabers (oder mehrere Sperrinhaber) 418, der Vektorzeit der letzten Freigabe 424426 sowie die Angabe aller Threads 420, welche auf die Sperre oder auf bestimmte Bedingungen dieses Objekts (Abbildung 4) warten 400.Objects 226420, which are used for synchronization (e.g. monitors, semaphores, read-write looks, etc.) also carry information about the lock, i.e. the specification of the lock holder (or several lock holders) 418, the vector time of the last release 424426 and the specification of all threads 420 which are waiting 400 for the lock or for certain conditions of this object (Figure 4).

[0025] Der Checker braucht schliesslich einen Pseudo-Zufallszahlen-Generator mit einem sog. Seed, um reproduzierbare Resultate zu ermöglichen. Es eignet sich eine Uniformverteilung der Zufallswerte, aber es sind auch andere Verteilungen verwendbar.Finally, the checker needs a pseudo-random number generator with a so-called seed in order to enable reproducible results. A uniform distribution of the random values is suitable, but other distributions can also be used.

Schritt 2: Eintrittsauswahl [0026] Der Mechanismus wählt einen zufälligen Einstiegspunkt in das Programm und setzt einen initialen lauffähigen Thread im Laufzeitmodel auf 200. Dieser Thread soll nach den möglichen statischen Initialisierungen des Programms und der Erzeugung möglicher initialer Objekte zum Ablauf geplant werden. Die Eintritte hängen vom Programmtyp ab: Für Konsolanwendungen ist dies in der Regel die initiale Main-Methode. Für GUI-Anwendungen ist dies eine initiale Ul-Komponente mit einer Serie von Ereignissen. Für Bibliotheken kann dies jeder öffentlich benutzbare (public) Member sein. Falls mehrere Eintritte möglich sind, wird eine zufällige Auswahl getroffen, z.B. ein zufälliger Member einer Bibliothek oder eine zufällige Serie von Ul-Ereignissen. Externe Parameter für solche Eintritte werden mit den speziellen «uninterpretierten» Werte zugewiesen.Step 2: Entry Selection The mechanism selects a random entry point into the program and sets an initial executable thread in the runtime model to 200. This thread is to be planned for the execution after the possible static initializations of the program and the generation of possible initial objects. Entries depend on the program type: For console applications, this is usually the initial main method. For GUI applications, this is an initial UI component with a series of events. For libraries this can be any public member. If multiple entries are possible, a random selection will be made, e.g. a random member of a library or a random series of ul events. External parameters for such entries are assigned with the special «uninterpreted» values.

Schritt 3: Zufallssimulation [0027] Dieser Mechanismus führt die folgenden Unterschritte aus (Abbildung 5) 500: In Schritt 3.1502 wird ein zufälliger lauffähiger Thread 204 ausgewählt und seine aktive Instruktion 216 für weitergehende Entscheidungen betrachtet 504510 550. Falls diese Instruktion keine Operanden mit «uninterpretierten» Werten hat 506, wird der analoge Effekt auf dem internen Laufzeitmodell simuliert 200, so wie sich diese Instruktion in einem echten Laufzeitsystem auswirken würde (Schritt 3.2) 508. Abhängig vom Instruktionstyp 510 werden zusätzliche Effekte durchgeführt: Bei Thread-Starts und Task-Starts 512 (Schritt 3.3a) wird der gestartete Thread mit dem aktuellen Thread synchronisiert und die Zeit des aktuellen Thread um eins fortgeschritten 514. Bei Thread-Joins oderTask-Waits 516 (Schritt 3.3b) geht die Zeit des aktuellen Threads weiter und der aktuelle Thread wird danach mit dem beendeten Ziel-Thread synchronisiert 518. Bei Sperrfreigaben (Unlocks) 520 (Schritt 3.3c) schreitet die Zeit des aktuellen Threads voran und wird im Synchronisationsobjekt vermerkt 522. Bei Sperrbezügen (Looks) 524 (Schritt 3.3d) synchronisiert sich der aktuelle Thread mit der im Synchronisationsobjekt vermerkten Zeit, bevor die Zeit des aktuellen Threads fortschreitet 526. Bei Variablen- oder Array-Element-Zugriffen 528 (Schritt 3.3e) wird der Zugriff zusammen mit der aktuellen Zeit als ein Zugriffsereignis beim zugreifenden Thread vermerkt 530. Bei einem synchronisierten Zugriff (z.B. atomar oder volatile in C# oder Java) synchronisiert sich zusätzlich der Thread mit der Zeit des letzten synchronisierten Zugriffs auf jenem Speicherort und die neue Zugriffszeit wird in dem Speicherort vermerkt. Bei API-Zugriffen oder Aufrufen 532 (Schritt 3.3f) wird dieser Zugriff ebenso mit der aktuellen Zeit als ein Zugriffsereignis beim aktuellen Thread vermerkt 534. Falls Instruktionen «uninterpretierte» Operanden aufweisen 548, wird je nach Instruktionstyp eine andere Aktion getätigt 550: Bei einer Verzweigung (Branch) 552 mit einer «uninterpretierten» Verzweigungsbedingung (Schritt 3.3g) wird eine zufällige Verzweigung gewählt 554. Bei allen anderen Instruktionen, welche «uninterpretierte» Operanden aufweisen 556 (Schritt 3.3h), resultieren «uninterpretierte» Werte 558.Step 3: Random Simulation This mechanism performs the following sub-steps (Figure 5) 500: In step 3.1502, a random executable thread 204 is selected and its active instruction 216 is considered 504510 550 for further decisions. If this instruction does not interpret any operands with «uninterpreted »Values has 506, the analog effect is simulated 200 on the internal runtime model, as this instruction would have in a real runtime system (step 3.2) 508. Depending on the instruction type 510, additional effects are carried out: For thread starts and task starts 512 (step 3.3a) the started thread is synchronized with the current thread and the time of the current thread is advanced by one 514. With thread joins or task waits 516 (step 3.3b) the time of the current thread continues and the current thread is then synchronized 518 with the terminated target thread. With unlocks 520 (Step 3.3c) the time of the current thread advances and is noted 522 in the synchronization object. In the case of lock references (looks) 524 (Step 3.3d) the current thread synchronizes with the time noted in the synchronization object before the time of the current thread progresses 526 With variable or array element accesses 528 (step 3.3e), the access together with the current time is noted 530 as an access event with the accessing thread. With a synchronized access (eg atomic or volatile in C # or Java), the thread additionally synchronizes with the time of the last synchronized access to that storage location and the new access time is noted in the storage location. In the case of API accesses or calls 532 (step 3.3f), this access is also noted 534 with the current time as an access event in the current thread. If instructions have "uninterpreted" operands 548, a different action is performed 550 depending on the instruction type: With one Branch 552 with an “uninterpreted” branching condition (step 3.3g) is a random branch 554. For all other instructions that have “uninterpreted” operands 556 (step 3.3h), “uninterpreted” values 558 result.

[0028] Nebenläufigkeitsfehler werden nach der Simulation bestimmter Instruktionen festgestellt 536538 540: Nach der Simulation des Sperrens eines Objektes (Lock) 536 (Schritt 3.4a), welches den Thread blockiert hat, wird geprüft, ob eine zyklische Warteabhängigkeit unter den auf Sperren wartenden Threads entstanden ist 542. Falls dem so ist, wird ein Deadlock-Fehler aufgezeichnet. Nach dem Zugriff auf eine Variable oder ein Array-Element 538 (Schritt 3.4b) wird das entsprechende Zugriffsereignis mit allen anderen nebenläufigen Ereignissen aller anderen Threads verglichen 544, d.h. mit allen Ereignissen, welche keine «Happens-Before»-Beziehung in Bezug auf die Vektorzeiten in den Ereignissen haben. Falls zwei verglichene Zugriffsereignisse dieselbe Variable oder dasselbe Array-Element mit mindestens einem Schreibzugriff und wenigstens einem unsynchronisierten Zugriff (z.B. nicht atomar oder nicht volatile in C# oder Java) aufweisen, wird dies als Data Race Fehler aufgezeichnet 544. Nach einem API-Zugriff oder Aufruf 540 (Schritt 3.4c) wird der Zugriff resp. Aufruf mit allen nebenläufigen Zugriffsereignissen der anderen Threads betreffend dieses API verglichenConcurrency errors are determined after the simulation of certain instructions 536538 540: After simulating the locking of an object (lock) 536 (step 3.4a), which has blocked the thread, it is checked whether there is a cyclical waiting dependency among the threads waiting for locks resulted in 542. If so, a deadlock error is recorded. After accessing a variable or array element 538 (step 3.4b), the corresponding access event is compared 544 to all other concurrent events of all other threads, i.e. with all events that have no happens-before relationship with respect to the vector times in the events. If two compared access events have the same variable or the same array element with at least one write access and at least one unsynchronized access (eg not atomic or non-volatile in C # or Java), this is recorded 544 as a data race error. After an API access or call 540 (step 3.4c) the access resp. Call compared to all concurrent access events of the other threads regarding this API

546. Falls zwei Zugriffe hinsichtlich der Beschreibung der Thread-Sicherheit ein Konflikt verursachen (z.B. Methoden auf demselben nicht Thread-sicheren Objekt einer Collection) wird dies als Fehler im Sinne einer Thread-unsicheren API-Verwendung aufgezeichnet 546. Alle aufgezeichneten Fehler werden gesammelt und über die Dauer des gesamten CheckerMechanismus beibehalten.546. If two accesses conflict with regard to the description of thread security (eg methods on the same non-thread-safe object of a collection), this is recorded as an error in the sense of a thread-unsafe API use 546. All recorded errors are collected and maintained for the duration of the entire checker mechanism.

[0029] In der Folge 560-564 schreitet der Thread zu seiner nächsten Instruktion fort, sofern er durch die Instruktionssimulation nicht blockiert oder terminiert worden ist (Schritt 3.5) 566. Garbage Collection wird regelmässig simuliert (Schritt 3.6) 568 und, falls ein Objekt mit einem Finalizer als Garbage erkannt worden ist, wird dessen Finalizer als lauffähigen Thread für den Ablauf geplant, wobei sich dieser Thread mit allen anderen existierenden Threads synchronisiert.In the sequence 560-564, the thread proceeds to its next instruction, provided that it has not been blocked or terminated by the instruction simulation (step 3.5) 566. Garbage collection is regularly simulated (step 3.6) 568 and, if an object If a finalizer has been recognized as garbage, its finalizer is planned as an executable thread for execution, this thread being synchronized with all other existing threads.

[0030] Die Simulation weist zwei Schranken auf: Eine Schranke pro Rund und eine gesamte Schranke für die ganze Simulation sowie eine weitere für die Grösse des in der Simulation allozierten Speichers. Falls die gesamte Schranke erreicht worden ist 570 572, läuft die Simulation in Schritt 4 weiter 574 108. Anderenfalls 576, d.h. wenn die Schranke pro Runde erreicht oder das Programm beendet worden ist 578 580, wird das interne Modell zurückgesetzt und die Simulation beginnt erneut in Schritt 2 582 104. Falls keiner diese Fälle zutrifft 584, geht der Mechanismus in Schritt 3 über 586106, worin es mit Schritt 3.1 weitergeht 502.The simulation has two barriers: one barrier per round and an entire barrier for the entire simulation, and another for the size of the memory allocated in the simulation. If the entire barrier has been reached 570 572, the simulation continues in step 4 574 108. Otherwise 576, i.e. if the barrier per lap has been reached or the program has ended 578 580, the internal model is reset and the simulation starts again in step 2 582 104. If none of these cases applies 584, the mechanism goes to step 3 via 586106, which involves Step 3.1 continues 502.

[0031] Die Schranken sind einstellbar. Nützliche Resultate wurden für grössere C#-Projekte mit einer Schranke pro Runde von 100 000 Schritten und einer Gesamtschranke von 1 000 000 Schritten sowie einer Speicherschranke von 100 MB pro Runde erreicht.The barriers are adjustable. Useful results were achieved for larger C # projects with a barrier of 100,000 steps per lap and a total barrier of 1,000,000 steps and a memory barrier of 100 MB per lap.

Schritt 4: Fehlerbericht [0032] Der Checker aggregiert alle Fehler, die in Schritt 3 gesammelt worden sind 106 542 544 546, streicht alle Duplikate heraus und meldet schliesslich diese Fehler.Step 4: Error Report The checker aggregates all the errors collected in step 3 106 542 544 546, deletes all duplicates and finally reports these errors.

Patent-Referenzen [0033] [P1 ] US 8 510 722 B2. Detecting data race and atomicity violation via typestate-guided static analysis.Patent References [P1] US 8 510 722 B2. Detecting data race and atomicity violation via typestate-guided static analysis.

[P2] US 8 510 604 B2. Static data race detection and analysis.[P2] US 8 510 604 B2. Static data race detection and analysis.

[P3] US 20 120 204 062 A1. Data race detection.[P3] US 20 120 204 062 A1. Data race detection.

[P4] US 20 070 245 312 A1. Precise data-race detection using locksets.[P4] US 20 070 245 312 A1. Precise data-race detection using locksets.

[P5] US 20 070 011 671 A1. Method for the static analysis of concurrent multi-threaded Software.[P5] US 20 070 011 671 A1. Method for the static analysis of concurrent multi-threaded software.

[P6] US 20 020 129 306 A1. Method and apparatus for verifying data local to a Single thread.[P6] US 20 020 129 306 A1. Method and apparatus for verifying data local to a single thread.

[P7] US 7 685 572 B1. Method of static analysis for race condition detection.[P7] US 7,685,572 B1. Method of static analysis for race condition detection.

[P8] US 6 343 371 B1. System and method for statically detecting potential race conditions in multi-threaded Computer programs.[P8] US 6,343,371 B1. System and method for statically detecting potential race conditions in multi-threaded computer programs.

[P9] US 20 110 167 412 A1. Universal causality graphs for bug detection in concurrent programs.[P9] US 20 110 167 412 A1. Universal causality graphs for bug detection in concurrent programs.

[P10] US 20 080 184 252 A1. Methods and apparatus for detecting deadlock in multithreading programs.[P10] US 20 080 184 252 A1. Methods and apparatus for detecting deadlock in multithreading programs.

[P11] US 6 593 940 B1. Method for finding errors in multithreaded applications.[P11] US 6 593 940 B1. Method for finding errors in multithreaded applications.

[P12] US 7 657 894 B2. Detecting lock acquisition hierarchy violations in multithreaded programs.[P12] US 7,657,894 B2. Detecting lock acquisition hierarchy violations in multithreaded programs.

[P13] US 8713568 B2. System and method for detecting deadlock in a multithread program.[P13] US 8713568 B2. System and method for detecting deadlock in a multithread program.

[P14] US 2015 095 894 A1. Detecting race condition vulnerabilities in Computer Software applications.[P14] US 2015 095 894 A1. Detecting race condition vulnerabilities in computer software applications.

[P15] WO 2014 184 612 A1. Method and device for detecting a race condition and a Computer program product.[P15] WO 2014 184 612 A1. Method and device for detecting a race condition and a Computer program product.

[P16] CN 104 090 798 A. Dynamic and static combined Interrupt drive program data race detection method.[P16] CN 104 090 798 A. Dynamic and static combined Interrupt drive program data race detection method.

[P17] CN 104 077 144 A. Data race detection and evidence generation method based on multithreaded program constraint building.[P17] CN 104 077 144 A. Data race detection and evidence generation method based on multithreaded program constraint building.

[P18] CN 104 156 262 A. Concurrent program deadlock detection method based on Petri network MIP method.[P18] CN 104 156 262 A. Concurrent program deadlock detection method based on Petri network MIP method.

[P19] CN 102 073 589 B. Code static analysis-based data race detecting method and System thereof.[P19] CN 102 073 589 B. Code static analysis-based data race detecting method and system thereof.

[P20] US 7 469 403 B2. Static detection of a datarace condition for multithreaded object-oriented applications.[P20] US 7,469,403 B2. Static detection of a datarace condition for multithreaded object-oriented applications.

[P21] US 7 549 150 B2. Method and System for detecting potential races in multithreaded programs.[P21] US 7,549,150 B2. Method and System for detecting potential races in multithreaded programs.

[P22] US 7 673 181 B1. Detecting race conditions in Computer programs.[P22] US 7 673 181 B1. Detecting race conditions in computer programs.

[P23] US 8 185 875 B2. Fast and accurate static data-race detection for concurrent programs.[P23] US 8 185 875 B2. Fast and accurate static data-race detection for concurrent programs.

[P24] US 8 464 223 B2. Method and apparatus for efficient and precise datarace detection for multithreaded object-oriented programs.[P24] US 8,464,223 B2. Method and apparatus for efficient and precise datarace detection for multithreaded object-oriented programs.

[P25] US 8 533 681 B2. Atomicity violation detection using access interleaving invariants.[P25] US 8 533 681 B2. Atomicity violation detection using access interleaving invariants.

[P26] US 8 539 450 B2. Fast and accurate data race detection for concurrent programs with asynchronous calls.[P26] US 8 539 450 B2. Fast and accurate data race detection for concurrent programs with asynchronous calls.

[P27] US 20 030 131 283 A1. Race détections for parallel Software.[P27] US 20 030 131 283 A1. Race détections for parallel software.

[P28] US 20 100 131 931 AU. Sampling techniques for dynamic data-race detection.[P28] US 20 100 131 931 AU. Sampling techniques for dynamic data-race detection.

[P29] US 20 110 131 550 A1. Concurrency Software Testing with Probabilistic Bounds on Finding Bugs.[P29] US 20 110 131 550 A1. Concurrency Software Testing with Probabilistic Bounds on Finding Bugs.

[P30] US 20 120 278 792 A1. Automatic Vérification and Synthesis for Weak Memory Models.[P30] US 20 120 278 792 A1. Automatic Verification and Synthesis for Weak Memory Models.

[P31] US 7 366 956 B2. Detecting data races in multithreaded Computer programs.[P31] US 7 366 956 B2. Detecting data races in multithreaded computer programs.

[P32] US 7 401 208 B2. Method and apparatus for randomizing instruction thread interleaving in a multi-thread processor. [P33] US 20 050 177 775 A1. Data race detection using sequential program analysis.[P32] US 7,401,208 B2. Method and apparatus for randomizing instruction thread interleaving in a multi-thread processor. [P33] US 20 050 177 775 A1. Data race detection using sequential program analysis.

[P34] US 20 110 314 338 A1. Data collisions in concurrent programs.[P34] US 20 110 314 338 A1. Data collisions in concurrent programs.

[P35] CN 104 978 272 A. Program scheduling method for data race detection.[P35] CN 104 978 272 A. Program scheduling method for data race detection.

[P36] US 9 052 967 B2. Detecting resource deadlocks in multi-threaded programs by Controlling scheduling in replay. [P37] US 9 135 082 B1. Techniques and Systems for data race detection.[P36] US 9 052 967 B2. Detecting resource deadlocks in multi-threaded programs by Controlling scheduling in replay. [P37] US 9 135 082 B1. Techniques and systems for data race detection.

[P38] US 8 200 474 B2. Dynamic model checking with property driven pruning to detect race conditions.[P38] US 8 200 474 B2. Dynamic model checking with property driven pruning to detect race conditions.

[P39] US 6 009 269 A. Detecting concurrency errors in multi-threaded programs.[P39] US 6,009,269 A. Detecting concurrency errors in multi-threaded programs.

[P40] US 9 081 628 B2. Detecting potential access errors in a multi-threaded application.[P40] US 9 081 628 B2. Detecting potential access errors in a multi-threaded application.

[P41] US 7 174 554 B2. Tools and methods for discovering race condition errors.[P41] US 7 174 554 B2. Tools and methods for discovering race condition errors.

Andere Referenzen [0034] [AH+91] S. Adve, M. Hill, B. Miller, and R. Netzer. Detecting Data Races on Weak Memory Systems. In Proceedings of the 18th Annual International Symposium on Computer Architecture, 1991.Other References [AH + 91] S. Adve, M. Hill, B. Miller, and R. Netzer. Detecting data races on weak memory systems. In Proceedings of the 18th Annual International Symposium on Computer Architecture, 1991.

[0035] [CB+01] E. Clarke, A. Biere, R. Raimi, and Y. Zhu. Bounded Model Checking Using Satisfiability Solving. Formai Methods in System Design, Vol. 19, pp. 7-34, 2001.[CB + 01] E. Clarke, A. Biere, R. Raimi, and Y. Zhu. Bounded Model Checking Using Satisfiability Solving. Formai Methods in System Design, Vol. 19, pp. 7-34, 2001.

[0036] [CM12] P. Cousot and M. Monerau. 2012. Probabilistic Abstract Interpretation. Proceedings of the 2lst European Conference on Programming Languages and Systems, Springer-Verlag, 2012.[CM12] P. Cousot and M. Monerau. 2012. Probabilistic Abstract Interpretation. Proceedings of the 2lst European Conference on Programming Languages and Systems, Springer-Verlag, 2012.

[0037] [EA03] D. Engler and K. Ashcraft. RacerX: Effective, Static Detection of Race Conditions and Deadlocks. Proceedings of the 19th ACM Symposium on Operating Systems Principles, pp. 237-252, 2003.[EA03] D. Engler and K. Ashcraft. RacerX: Effective, Static Detection of Race Conditions and Deadlocks. Proceedings of the 19th ACM Symposium on Operating Systems Principles, pp. 237-252, 2003.

[0038] [FF09] C. Flanagan and S. N. Freund. FastTrack: Efficient and Precise Dynamic Race Detection. ACM SIGPLAN Notices, v.44 n.6, June 2009.[FF09] C. Flanagan and S.N. Freund. FastTrack: Efficient and Precise Dynamic Race Detection. ACM SIGPLAN Notices, v.44 n.6, June 2009.

[0039] [GN05] S. Gulwani and G. C. Necula. Precise Interprocedural Analysis using Random Interpretation. Proceedings of the 32nd Annual ACM Symposium on Principles of Programming Languages, 2005.[GN05] S. Gulwani and G.C. Necula. Precise Interprocedural Analysis using Random Interpretation. Proceedings of the 32nd Annual ACM Symposium on Principles of Programming Languages, 2005.

[0040] [Gul05] S. Gulwani. Program Analysis using Random Interpretation. Phd Dissertation, UC-Berkeley, 2005.[Gul05] S. Gulwani. Program analysis using random interpretation. PhD dissertation, UC-Berkeley, 2005.

[0041] [HOG14] J. Huang, P. O’Neil Meredith, and G. Rosu, Maximal Sound Prédictive Race Detection with Control Flow Abstraction. Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation, Edinburgh, United Kingdom, 2014.[HOG14] J. Huang, P. O'Neil Meredith, and G. Rosu, Maximal Sound Predictive Race Detection with Control Flow Abstraction. Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation, Edinburgh, United Kingdom, 2014.

[0042] [JPF] Java Pathfinder: Framework for Vérification of Java Programs. http://babelfish.arc.nasa.gov/trac/jpf/. Last accessed 2016-11-04.[JPF] Java Pathfinder: Framework for Verification of Java Programs. http://babelfish.arc.nasa.gov/trac/jpf/. Last accessed 2016-11-04.

[0043] [KPP12] A. Khyzha, P. Parizek, and C. S. Päsäreanu. Abstract Pathfinder. SIGSOFT Software Engineering Notes 37, 6(ll):l-5, 2012.[KPP12] A. Khyzha, P. Parizek, and C. S. Päsäreanu. Abstract pathfinder. SIGSOFT Software Engineering Notes 37, 6 (ll): l-5, 2012.

[0044] [KYS+07] V. Kahlon, Y. Yang, S. Sankaranarayanan, and A. Gupta. Fast and Accurate Static Data-Race Detection for Concurrent Programs. Proceedings of the 19th International Conference on Computer Aided Vérification, Berlin, Germany, 2007.[KYS + 07] V. Kahlon, Y. Yang, S. Sankaranarayanan, and A. Gupta. Fast and Accurate Static Data-Race Detection for Concurrent Programs. Proceedings of the 19th International Conference on Computer Aided Vérification, Berlin, Germany, 2007.

[0045] [Lam78] L. Lamport. Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7):558- 565, 1978.[Lam78] L. Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21 (7): 558-565, 1978.

[0046] [Me91] J. Mellor-Crummey. 1991. On-the-Fly Detection of Data Races for Programs with Nested Fork-Join Parallelismi. Proceedings of the 1991 ACM/IEEE Conference on SuperComputing, 1991.[Me91] J. Mellor-Crummey. 1991. On-the-Fly Detection of Data Races for Programs with Nested Fork-Join Parallelismi. Proceedings of the 1991 ACM / IEEE Conference on SuperComputing, 1991.

[0047] [MMN09] D. Marino, M. Musuvathi, and S. Narayanasamy. LiteRace: Effective Sampling for Lightweight Data-Race Detection. ACM SIGPLAN Notices, v.44 n.6, 2009.[MMN09] D. Marino, M. Musuvathi, and S. Narayanasamy. LiteRace: Effective Sampling for Lightweight Data-Race Detection. ACM SIGPLAN Notices, v.44 n.6, 2009.

[0048] [MQB07] M. Musuvathi, S. Qadeer, andT. Ball. CHESS: ASystematicTestingTool for Concurrent Software. Microsoft Research Technical Report MSR-TR-2007-149, 2007.[MQB07] M. Musuvathi, S. Qadeer, andT. Ball. CHESS: ASystematicTestingTool for Concurrent Software. Microsoft Research Technical Report MSR-TR-2007-149, 2007.

[0049] [NAW06] M. Naik, A. Aiken, and J. Whaley. Effective Static Race Detection for Java. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 20-29, 2006.[NAW06] M. Naik, A. Aiken, and J. Whaley. Effective Static Race Detection for Java. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 20-29, 2006.

[0050] [PFH06] P. Pratikakis, J. Foster, and M. Hicks. LOCKSMITH: Context-Sensitive Corrélation Analysis for Race Detection. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 320331,2006.[PFH06] P. Pratikakis, J. Foster, and M. Hicks. LOCKSMITH: Context-Sensitive Corrélation Analysis for Race Detection. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 320331.2006.

[0051] [PG03a] C. Praun and T. Gross. Object Race Detection. Proceedings of the ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages and Applications, pp. 70-82, 2003.[PG03a] C. Praun and T. Gross. Object race detection. Proceedings of the ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages and Applications, pp. 70-82, 2003.

[0052] [PG03b] C. Praun and T. Gross. Static Conflict Analysis for Multi-Threaded Object-Oriented Programs. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 115-128, 2003.[PG03b] C. Praun and T. Gross. Static Conflict Analysis for Multi-Threaded Object-Oriented Programs. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 115-128, 2003.

[0053] [SBN+97] S. Savage, M. Burrows, G. Nelson, P. Sobalvarro, and T. E. Anderson. Eraser: A Dynamic Data Race Detector for Multi-Threaded Programs. ACM Transactions on Computer Systems, 15(4):391-411, 1997.[SBN + 97] S. Savage, M. Burrows, G. Nelson, P. Sobalvarro, and T.E. Anderson. Eraser: A Dynamic Data Race Detector for Multi-Threaded Programs. ACM Transactions on Computer Systems, 15 (4): 391-411, 1997.

[0054] [SI09] K. Serebryany and T. Iskhodzhanov. ThreadSanitizer: Data Race Detection in Practice. Proceedings of the Workshop on Binary Instrumentation and Applications, New York, 2009.[SI09] K. Serebryany and T. Iskhodzhanov. ThreadSanitizer: Data Race Detection in Practice. Proceedings of the Workshop on Binary Instrumentation and Applications, New York, 2009.

[0055] [Ster93] N. Sterling. Warlock: A Static Data Race Analysis Tool. USENIX Winter Technical Conference, 1993.[Ster93] N. Sterling. Warlock: A Static Data Race Analysis Tool. USENIX Winter Technical Conference, 1993.

[0056] [XXII] X. Xie and J. Xue. Acculock: Accurate and Efficient Detection of Data Races, Proceedings of the 9th Annual IEEE/ACM International Symposium on Code Generation and Optimization, p.201-212, 2011.[XXII] X. Xie and J. Xue. Acculock: Accurate and Efficient Detection of Data Races, Proceedings of the 9th Annual IEEE / ACM International Symposium on Code Generation and Optimization, p.201-212, 2011.

Claims

claims

1. A method for error detection in a program without having to execute it, a so-called static analysis, the method comprising the following:

• A repeated simulation of the program execution on an internal runtime representation of the recognition mechanism, • the use of a randomized scheduling of the threads or processes in the simulation, • the application of limits on the simulation time and size, • the analysis and the report on the occurrence of specific states or effects in the simulation that represent program errors.

2. The method of claim 1, which uses uninterpreted (not interpreted) states in the internal runtime representation for unsupported or incomplete program parts and external input / output, so that:

• Uninterpreted states result from the operations that have uninterpreted states in the operands, • The simulation branches out at random with conditions with reinterpreted states.

3. The method of claim 1, in that it is used for the detection of data races or thread-insecure use of application programming interfaces (APIs), with vector times being used in the simulation.

4. The method of claim 1, by using it for the detection of deadlocks, wherein a cyclical waiting dependency is searched among the threads during the locking attempts in the simulation.

5. A system that looks for errors by analyzing program source code or compiled program code of any programming language or a runtime system using the method of claim 1.

6. One or more computer media containing the program code which, when executed, carries out the detection of errors using the method of claim 1.

DRAWINGS

illustration 1

100 static / global

200

300

Image u n p óì-

400

ADDI aung

500