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: This disclosure relates to exposing memory cell values prior to execution time(s) corresponding to events that caused the memory cell values to be recorded into a trace. Trace fragments, including a first trace fragment and a second trace fragment, are identified within a trace. Each trace fragment records an uninterrupted consecutive execution of executable instructions on a corresponding thread. The first trace fragment can be ordered prior to the second trace fragment. It is determined that a memory cell value can be exposed, during replay of the second fragment, at a first execution time that is prior to a second execution time corresponding to an event that caused the memory cell value to be recorded into the trace during trace recording. Output data is generated which indicates that the memory cell value can be exposed at the first execution time during replay of the second trace fragment.

Abstract: A code entity of an application, for which a differential analysis is to be performed, is identified in a replayable trace of a prior execution of the application. A prior invocations of the code entity are replayed by re-executing executable instructions of the code entity based on the replayable trace. Based on the replay, a families of invocations of the code entity are identified. Each family is defined based upon attributes that identify at least one class of runtime behavior of the code entity that is observed during the replay of the invocations of the code entity. First attributes of a first family that substantially contribute to classifying a first class of invocations of the code entity within the first family are identified, and second attributes of a second family that substantially contribute to classifying a second class of invocations of the code entity within the second family are identified.

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 present disclosure relates to emulating non-traced code with a recorded execution of traced code. For example, embodiments access a replayable recorded execution of a prior execution of first executable code. The replayable recorded execution includes one or more inputs that were consumed by one or more first executable instructions during the prior execution of the first executable code. Second executable code, which is different from the first executable code, is also accessed. Execution of second executable code not is recorded in the replayable recorded execution. Execution of the second executable code is emulated using the one or more inputs from the replayable recorded execution. Embodiments might report differences between the emulated execution of the second executable code and the prior execution of the first executable code may be reported, or equivalency between the emulated execution of the second executable code and the prior execution of the first executable code.

Abstract: Using synthetic inputs to determine if different versions of executable code execute equivalently. First and second versions of code are accessed. Based on recorded execution(s), a first code path is identified in the first code version that lacks execution coverage. A second code path is identified in the second code version that maps to the first code path. Synthetic inputs are generated for the first code path. The first and second code paths are emulated using the generated synthetic inputs, resulting in first outputs for the first code path and second outputs for the second code path. It is determined if there are any differences between the first and second outputs. If so, it is reported that the first and second code paths do not execute equivalently when supplied with the synthetic inputs. Otherwise, it is reported that the first and second code paths execute equivalently.

Abstract: Mapping input locations to enable execution of second executable code using trace data gathered during execution of first executable code. A trace of a prior execution of the first code, and the second code, are accessed. The trace stores data of an input that was consumed by first executable instructions of the first code. It is determined that the stored data of the input is usable as an input to second executable instructions of the second code. A difference in how the first instructions accessed the input during recording, as compared to how the second instructions expect to access input, is identified. Based on the identified difference, a location transformation is determined that would enable the second instructions to access the stored data. Execution of the second instructions is emulated using the stored data, including projecting the location transformation to enable the second instructions to access the stored data.

Abstract: Determining if a function's behavioral change affects a client function. A first function, as well as a recorded execution of the first function, are accessed. A second function that is associated with a behavioral change is identified. The first function is identified as a client of the second function. The first function is emulated in view of the behavioral change associated with the second function. It is determined if the first function executed differently during emulation, based on the behavioral change associated with the second function. The determination is based on comparing the emulated execution of the first function with the recorded execution of the first function. A report is generated, reporting whether or not the first function executed differently based on the behavioral change associated with the second function.

Abstract: Transforming input data to enable execution of second executable code using trace data gathered during execution of first executable code. A trace of an execution of the first code is accessed. The trace stores data of an input that was consumed by first executable instructions of the first code. It is determined that the stored data of the input is usable as an input to second executable instructions of the second code. A difference in size/format of the stored data as used by the first instructions, compared to an input size/format expected by the second executable instructions, is identified. Based on the identified difference, a data transformation is determined that would enable the second instructions to consume the stored data. Execution of the second instructions is emulated using the stored data, including projecting the data transformation to enable the second instructions to consume the stored data.

Abstract: Emulating execution of second code of a second instruction set architecture (ISA) using a trace of execution of first code of a first ISA. The stores data of an input that was consumed by the first code when executing on the first ISA. It is determined that the stored data of the input is usable as an input to the second code. Difference(s) in location/size/format of the stored data as used by the first code, compared to a location/size/format expected by the second code, is identified. Based on the identified difference(s), transformation(s) are determined that would enable the second code to access and consume the stored data when being emulated on the second ISA. Execution of the second code is emulated on the second ISA using the stored data, including projecting the transformation(s) to enable the second code to access and consume the stored data.

Abstract: Using synthetic inputs during an emulated execution from a recorded execution to reach a code path not recorded in the recorded execution. Recorded execution(s) of an executable entity are accessed. These recorded execution(s) include recorded inputs that were consumed during prior execution(s) of the executable entity. Code path(s), which have no recorded execution coverage in the recorded execution(s), are identified. Execution of the identified code path(s) is emulated using synthetic inputs. The emulated execution includes emulating execution of first executable instruction(s) using the recorded inputs to reach an execution point preceding the code path(s); generating the synthetic inputs, which would cause second executable instruction(s) of the code path(s) to be executed; and using the synthetic inputs to emulate execution of the second executable 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: Querying resource lifetime using a trace of program execution. An embodiment includes identifying a query expression targeted at least a portion of the trace of program execution. The query expression specifies at least (i) a data object representing a plurality of events identified in the trace, each event associated with one or more attributes relating to resource lifetime, and (ii) one or more conditions matching the one attributes relating to resource lifetime. In response to receiving the query expression, the query expression is processed based at least on an analysis of an identified subset of the trace. Based on processing the query expression, a result data set that includes or identifies at least one of the plurality of events that meets the one or more conditions is presented.

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.

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: 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. A create task function is modified to include the setting of an indicator that a newly created task is to be traced if a current task or thread is being traced. An execute task function is modified to request the tracing of the newly created task when it is executed based on the indicator, thereby enabling selective tracing that operates across process boundaries and traces asynchronous code execution.

Abstract: Performing breakpoint detection via a cache includes detecting an occurrence of a memory access and identifying whether any cache line of the cache matches an address associated with the memory access. When a cache line does match the address associated with the memory access no breakpoint was encountered. When no cache line matches the address associated with the memory access embodiments identify whether any cache line matches the address associated with the memory access when one or more flag bits are ignored. When a cache line does match the address associated with the memory access when the one or more flag bits are ignored, embodiment perform a check for whether a breakpoint was encountered. Otherwise, embodiments process a cache miss.

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: Described technologies aid execution control during replays of traced program behavior. Cross-level mapping correlates source code, an intermediate representation, and native instructions in a trace. The trace includes a record of native code instructions which were executed by a runtime-managed program. The trace does not include any executing instance of the runtime. Breakpoints are set to align trace locations with source code expressions or statements, and to skip over garbage collection and other code unlikely to interest a developer. A live debugging environment is adapted to support trace-based reverse execution. An execution controller in a debugger or other tool may utilize breakpoint ranges, cross-level mappings, backward step-out support, and other items to control a replay execution of the trace.