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: This disclosure relates to creating memory snapshots that reduce processing for thread-focused analysis. A plurality of trace fragments is identified, each representing an uninterrupted consecutive execution of executable instructions on a corresponding thread of a plurality of threads. The trace fragments include a first and a second fragment corresponding to a first thread, and a third fragment corresponding to a second thread. An ordering among the fragments is determined. In the ordering, the first fragment is orderable prior to the second fragment on the first thread, and the third fragment is orderable between the first and second fragments. Based on the third fragment being orderable between the first and second fragments, a memory cell is identified that is interacted with by executable instructions whose execution is represented by the third trace fragment. Memory snapshot data identifying the memory cell is inserted into trace data corresponding to the first thread.

Abstract: Embodiments relate to a virtualization layer capturing replayable execution traces of VMs managed by the virtualization layer. Execution tracing can be performed on any unit of execution managed by the virtualization layer, e.g., threads, processes, virtual processors, individual VMs, multiple VMs, etc. Traced execution units may be executing in parallel. Execution tracing involves capturing to a buffer: executed instructions, memory inputted to instructions, memory outputted by instructions, registers touched by instructions, and ordering markers. Trace data can be captured in chunks, where causality is preserved and ordering is preserved between chunks but not necessarily within chunks. The chunks may be delineated by inserting monotonically increasing markers between context switches, thus relatively ordering the chunks. Determinism may be partially provided by identifying non-deterministic events. VM tracing may be transparent to guest software, which need not be instrumented.

Abstract: Recording a replay-able trace of execution of a multi-threaded process includes identifying a trace memory model that defines one or more orderable events that are to be ordered across a plurality of threads of the multi-threaded process. The plurality of threads are executed concurrently across one or more processing units of one or more processors. During execution of the plurality of threads, a separate replay-able trace is recorded for each thread independently. Recording includes, for each thread, recording initial state for the thread, recording at least one memory read performed by at least one processor instruction executed by the thread that takes memory as input, and recording a least one orderable event performed by the thread with a monotonically increasing number that orders the event among other orderable events across the plurality of threads.

Abstract: Performing a targeted partial recording of an executable entity includes executing the executable entity at a processor. While executing the executable entity, it is determined that a target chunk of executable instructions are to be executed as part of the execution of the executable entity. Each input to the target chunk of executable instructions is identified, including identifying at least one non-parameter input. A corresponding value for each identified input is recorded into a trace, along with information identifying the target chunk of executable instructions.

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: Utilizing diffgrams for trace indexing and replay. A subset of instructions of a trace, beginning with a first instruction and ending with a second instruction, are replayed to obtain state of one or more named resources. Based on replaying the subset of instructions, a diffgram is generated, which is structured such that addition of the diffgram at the first instruction brings the one or more named resources to the second state, and subtraction of the diffgram at the second instruction brings the one or more named resource to the first state. A pat of reaching a target instruction, the diffgram is later added at the first instruction to restore the second state at the second instruction, or subtracted at the second instruction to restore the first state of the first instruction.

Abstract: Determining whether a function-internal load modification affects the output of a traced function. A function is identified within a traced portion of a prior execution of an entity. The function comprises a sequence of executable instructions and produces one or more outputs. Traced output data value(s) that were produced by the traced instance of the function are determined, and an executable instruction within the sequence of executable instructions that performs a load from memory is identified. Execution of the function is emulated, while substituting a traced memory value loaded by the executable instruction during the traced instance of the function with a different memory value, and while producing emulated output data values(s). Based on there being a difference between the traced output data values(s) and the emulated output data values(s), a notification is generated at a user interface or to a software component.

Abstract: Determining whether a function-internal load modification affects the output of a traced function. A function is identified within a traced portion of a prior execution of an entity. The function comprises a sequence of executable instructions and produces one or more outputs. Traced output data value(s) that were produced by the traced instance of the function are determined, and an executable instruction within the sequence of executable instructions that performs a load from memory is identified. Execution of the function is emulated, while substituting a traced memory value loaded by the executable instruction during the traced instance of the function with a different memory value, and while producing emulated output data values(s). Based on there being a difference between the traced output data values(s) and the emulated output data values(s), a notification is generated at a user interface or to a software component.

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: Recording a replay-able trace of execution of a multi-threaded process includes identifying a trace memory model that defines one or more orderable events that are to be ordered across a plurality of threads of the multi-threaded process. The plurality of threads are executed concurrently across one or more processing units of one or more processors. During execution of the plurality of threads, a separate replay-able trace is recorded for each thread independently. Recording includes, for each thread, recording initial state for the thread, recording at least one memory read performed by at least one processor instruction executed by the thread that takes memory as input, and recording a least one orderable event performed by the thread with a monotonically increasing number that orders the event among other orderable events across the plurality of threads.

Abstract: The disclosure relates to embodiments, implemented at least partially in microcode, that use cache misses to trigger logging to a processor trace. One embodiment relies on tracking bits in a processor cache. During a transition from a non-logged context to a logged context, this embodiment invalidates or evicts cache lines whose tracking bits are not set. When logging, this first embodiment logs during cache misses, and sets tracking bits for logged cache lines. Another embodiment relies on way-locking. This second embodiment assigns first ways to a logged entity and second ways to a non-logged entity. The second embodiment ensures the logged entity cannot read cache lines from the second logging ways by flushing the second way during transitions from non-logging to logging, ensures the logged entity cannot read non-logged cache lines from the first ways, and logs based on cache misses into the first ways while executing a logged context.

Abstract: This disclosure relates to the use of execution traces to process queries against objects over their lifetime. Embodiments identify, from a trace, a memory-backed object that existed during a prior execution of an entity. A handle for logically representing memory covered by the object over the object's lifetime is identified. A plurality of associations that are represented by the handle are identified. These associations identify memory addresses that were covered by the object over its lifetime. Each association represents at least (i) a memory address that was covered by the object during its lifetime, and (ii) an execution time during the object's lifetime at which the memory address was covered by the object. A query is processed against the handle. The query includes a query based on an execution time, and processing the query includes comparing the execution time in the query to execution time(s) represented in the associations.

Abstract: Indexing and searching a bit-accurate trace for arbitrary length/arbitrary alignment values in traced thread(s). Indexing includes, while replaying a plurality of trace segments, identifying a set of n-grams for each trace segment that exist in processor data influx(es) and/or store(s) to a processor cache that resulted from replay of the trace segment. An index data structure, which associates each identified n-gram with trace location(s) at or in which the n-gram was found, is then generated. The index data structure thus associates unique n-grams with prior execution time(s) at or during which the traced thread(s) read or wrote the n-gram. Searching an indexed trace includes identifying n-grams in a query and using the index data structure to determine trace location(s) where these n-grams were seen during indexing. A query response is generated after using trace replay to locate particular execution time(s) and memory location(s) at which the n-grams occurred.

Abstract: Protecting sensitive information in connection with a trace of an original execution of an entity. Embodiments include identifying that original information—which was accessed based on an original execution of one or more original executable instructions of the entity—comprises sensitive information. Based on the original information comprising the sensitive information, embodiments include performing one or both of (i) storing first trace data comprising alternative information—rather than the original information, while ensuring that an execution path that was taken by the entity based on the original information is also taken during replay of the original execution of the entity; or (ii) storing second trace data that causes zero or more alternative executable instructions—rather than the one or more original executable instructions of the entity—to be executed during the replay of the original execution of the entity.

Abstract: A coprocessor stores at least part of an execution trace based on code execution at a primary processor. The coprocessor includes control logic that configures the coprocessor to listen to a bus that interconnects the primary processor and the coprocessor, and to receive one or more cache coherency protocol (CCP) messages from the bus (i.e., CCP message(s) sent on the bus by the primary processor, based on the primary processor having consumed data for a memory cell). Based on receiving the CCP message(s), the coprocessor initiates storing of the consumed data for the memory cell into an execution trace.

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: Recording a replay-able trace of execution of a multi-threaded process includes identifying a trace memory model that defines one or more orderable events that are to be ordered across a plurality of threads of the multi-threaded process. The plurality of threads are executed concurrently across one or more processing units of one or more processors. During execution of the plurality of threads, a separate replay-able trace is recorded for each thread independently. Recording includes, for each thread, recording initial state for the thread, recording at least one memory read performed by at least one processor instruction executed by the thread that takes memory as input, and recording a least one orderable event performed by the thread with a monotonically increasing number that orders the event among other orderable events across the plurality of threads.

Abstract: Expressly turning tracing on and off at each juncture between code that a developer wants to have traced and other code may reduce trace file size but adds computational cost. Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. The amount of extra tracing is balanced against the reduction in trace enablement/disablement operations by tuning thresholds, based on information about routine size and computational cost.