Abstract: Automatic identification of execution behavior(s) of software. This automatic identification is based on analysis of historical execution records using machine learning to identify a particular pattern that corresponds to an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record of that particular software is accessed. The execution record includes an execution trace that reproducibly represents the execution of the software within a particular execution environment, such that the execution record is usable to rerun the execution of the software precisely as the software previously run. Based on finding the particular pattern within the execution record, the computing system automatically identifies that the execution behavior is present within the software.

Abstract: Based on replay of a thread, one implementation observes an influx of a value of a memory cell comprising an interaction between the thread and the value of the memory cell at an execution time point in the replaying, and determines whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread at the execution time point. If so, this implementation initiates an indication of a data inconsistency. Based on replay of a plurality of threads, another implementation identifies a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, this implementation initiates an indication of a potential data contention.

Abstract: Based on replay of a thread, one implementation observes an influx of a value of a memory cell comprising an interaction between the thread and the value of the memory cell at an execution time point in the replaying, and determines whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread at the execution time point. If so, this implementation initiates an indication of a data inconsistency. Based on replay of a plurality of threads, another implementation identifies a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, this implementation initiates an indication of a potential data contention.

Abstract: Identifying and reporting potential data inconsistencies and/or potential data contentions based on historic debugging traces. Based on replay of a thread, some implementations observe an influx of a value to a memory cell, and determine whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread. If so, these implementations can initiate an indication of a data inconsistency. Based on replay of a plurality of threads, other implementations identify a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, these implementations might initiate an indication of a potential data contention.

Abstract: This disclosure relates to identifying and presenting differences between a plurality of recorded executions of an executable entity. One or more models are created over the plurality of recorded prior executions of at least a portion of an executable entity. These models include at least one of (i) a control flow model, or (ii) a data model. An anomalous model data point is identified within these models, and a first location in at least one of the plurality of recorded executions that corresponds to the anomalous model data point is identified. A second location in the at least one of the plurality of recorded executions is also identified. This second location is causal to the anomalous model data point at the first location. The identity of the first and/or second locations in the least one of the plurality of recorded executions is presented.

Abstract: Automatic identification of execution behavior(s) of software. This automatic identification is based on analysis of historical execution records using machine learning to identify a particular pattern that corresponds to an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record of that particular software is accessed. The execution record includes an execution trace that reproducibly represents the execution of the software within a particular execution environment, such that the execution record is usable to rerun the execution of the software precisely as the software previously run. Based on finding the particular pattern within the execution record, the computing system automatically identifies that the execution behavior is present within the software.

Abstract: Dynamically instrumenting code that executes based on a historic execution of a subject executable entity. Historic execution information for a subject executable entity is accessed. The historic execution information includes execution state information for at least one point in time in the historic execution the executable entity. Diagnostic code instruction(s) are identified, for instrumenting subject code instruction(s) of the executable entity. The subject code instruction(s) are virtually executed based at least on supplying the subject code instruction(s) with data from the historic execution information. While virtually executing the identified executable code instruction(s), the diagnostic code instruction(s) are also executed. The diagnostic code instruction(s) collecting diagnostic data regarding the virtual execution of the subject code instruction(s), or override at least one of a value or an execution behavior of the subject code instruction(s).

Abstract: The automatic identification of execution behavior(s) of software. This automatic identification is based on a historical analysis of execution records to identify a particular pattern that represents an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record (or perhaps multiple execution records) representing the execution of that particular software may be accessed. Based on finding the particular pattern within the execution record (or one, some, or all of the multiple execution records) representing the execution of that particular software, the computing system may automatically identify that the execution behavior is present within the software. This may dramatically assist in modifying that execution behavior.

Abstract: Techniques are provided to use historic execution state information to visualize tracepoint data. For example, historic execution state information corresponding to an application's previous execution is accessed. This historic execution state information was collected while the application was executing. After correlating the historic execution state information to the application's code, a tracepoint is associated with a portion of the code. Consequently, when the code is replayed based on the historic execution state information, the tracepoint causes a behavior of that code portion to be logged while the code is replayed uninterrupted. The code is then actually replayed based on the historic execution state information. During the replay, the tracepoint causes the behavior of the code portion to be logged. The logged behavior is visualized on a user interface.

Abstract: Identifying and reporting potential data inconsistencies and/or potential data contentions based on historic debugging traces. Based on replay of a thread, some implementations observe an influx of a value to a memory cell, and determine whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread. If so, these implementations can initiate an indication of a data inconsistency. Based on replay of a plurality of threads, other implementations identify a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, these implementations might initiate an indication of a potential data contention.

Abstract: The automatic identification of execution behavior(s) of software. This automatic identification is based on a historical analysis of execution records to identify a particular pattern that represents an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record (or perhaps multiple execution records) representing the execution of that particular software may be accessed. Based on finding the particular pattern within the execution record (or one, some, or all of the multiple execution records) representing the execution of that particular software, the computing system may automatically identify that the execution behavior is present within the software. This may dramatically assist in modifying that execution behavior.

Abstract: Techniques are provided to use historic execution state information to visualize tracepoint data. For example, historic execution state information corresponding to an application's previous execution is accessed. This historic execution state information was collected while the application was executing. After correlating the historic execution state information to the application's code, a tracepoint is associated with a portion of the code. Consequently, when the code is replayed based on the historic execution state information, the tracepoint causes a behavior of that code portion to be logged while the code is replayed uninterrupted. The code is then actually replayed based on the historic execution state information. During the replay, the tracepoint causes the behavior of the code portion to be logged. The logged behavior is visualized on a user interface.

Abstract: This disclosure relates to identifying and presenting differences between a plurality of recorded executions of an executable entity. One or more models are created over the plurality of recorded prior executions of at least a portion of an executable entity. These models include at least one of (i) a control flow model, or (ii) a data model. An anomalous model data point is identified within these models, and a first location in at least one of the plurality of recorded executions that corresponds to the anomalous model data point is identified. A second location in the at least one of the plurality of recorded executions is also identified. This second location is causal to the anomalous model data point at the first location. The identity of the first and/or second locations in the least one of the plurality of recorded executions is presented.

Abstract: Dynamically instrumenting code that executes based on a historic execution of a subject executable entity. Historic execution information for a subject executable entity is accessed. The historic execution information includes execution state information for at least one point in time in the historic execution the executable entity. Diagnostic code instruction(s) are identified, for instrumenting subject code instruction(s) of the executable entity. The subject code instruction(s) are virtually executed based at least on supplying the subject code instruction(s) with data from the historic execution information. While virtually executing the identified executable code instruction(s), the diagnostic code instruction(s) are also executed. The diagnostic code instruction(s) collecting diagnostic data regarding the virtual execution of the subject code instruction(s), or override at least one of a value or an execution behavior of the subject code instruction(s).