Microsoft Technology Licensing, LLC

Workman Nydegger

Patrick Nelson

Jackson Michael Davis

Del Myers

Thomas Lai

Jordi Mola

Sohail Baig Mohammed

Alexandre Vicktorovich Grigorovitch

Juan Carlos Arevalo Baeza

Kirt A Debique

Andrew R Sterland

Adil Ahmed Sherwani

Leslie Yvette Richardson

Sumedh N Barde

Shafiq Rahman

James M Pinkerton

Deborah Chen

Rebecca Claire Weiss

Geoffrey T Dunbar

Jonathan Marshall Cain

Kenneth W Sykes

Bret P O'Rourke

Gregg Bernard Miskelly

Richard William Saunders

Robin C B Speed

Samuel Ng

Khurshed Mazhar

Kevin P Larkin

Gregory Bernard Miskelly

Tedd Dideriksen

Robert Alan Paveza

Nikolaus Lee Karpinsky

Gearard Boland

Liqi Han

Michael John Novak

James Morris Alkove

Anders Edgar Klemets

Eric H Rudolph

Stephen Harris Toub

Kipley J Olson

Li-wei He

Henry Gabryjelski

Gurpratap Virdi

Stephen C Rowe

David M Nadalin

Mark Marron

Eric H Feiveson

Azeemullah Khan

Isadora Sophia Garcia Rodopoulos

Xiqiang Zhi

Gaurav Lochan

Cagri Aslan

Charles Joseph Ries

Andrew Joseph Luhrs

Timothy Gardner Misiak

Noah Falk

Techniques are described herein that are capable of detecting accidental algorithmic complexity of a procedure by using instrumentation. A number of times a parent procedure calls a child procedure during each of multiple executions of the parent procedure is detected by using instrumentation to provide call counts for the respective executions. A value of an attribute of the parent procedure during each of the executions is detected by using the instrumentation to provide attribute values for the respective executions. A function is generated that defines a curve that estimates a relationship between the attribute values for the respective executions and the call counts for the respective executions. Based at least on a slope of the curve, accidental algorithmic complexity of the parent procedure is determined. Based at least on the accidental algorithmic complexity satisfying a complexity criterion, a remedial action is performed with regard to the accidental algorithmic complexity.

Instrumentation-based detection of accidental algorithmic complexity of a procedure

A computer system is configured to profile a program during an execution of the program. Profiling the program includes obtaining, by a first profiler, a first set of information associated with the execution of the program, and obtaining a second set of information associated with one or more executions of the function. The second set of information includes at least a call count or an execution time of each of the one or more executions of the function. The computer system then identifies a subset of the first set of information that is associated with the one or more executions of the function, and creates aggregate information based on the subset of the first set of information and the second set of information. The aggregated information is then reported.

Profiling a program based on a combination of dynamic instrumentation and sampling

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.

Identifying data inconsistencies and data contention based on historic debugging traces

To set data breakpoints on properties and certain other functions, constituent data locations (CDLs) that can contribute to computation of the property value or other function result are identified, and respective constituent data breakpoints are added at one or more CDLs by data breakpoint adder code. Each constituent data breakpoint will suspend execution of an inspectable software in response to occurrence of a CDL data entry. The CDLs are identified by CDL identifier code using static data flow analysis, enhanced interpretation, or disassembly, with recursion as appropriate. Kernel or runtime routines, and other routines designated as known, can be excluded from the CDL search. Data locations marked read-only, or that are effectively read-only because they will not be written, can also be excluded. The resulting data breakpoint functionality makes internal program state information available, thus facilitating computing system accuracy, flexibility, security, speed, memory usage efficiency, and other functional characteristics.

Data breakpoints on certain kinds of functions

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. Operation of the trace controller is illustrated by sample APIs, a tracing state diagram, and a side-by-side comparison, among other items.

Selectively tracing portions of computer process execution

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.

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.

Automatically identifying and highlighting differences between historic traces

Performing reverse execution debugging of an application. The method includes identifying a snapshot of application state for an application in an application framework. The method further includes emulating execution of the application, using bytecode, in a forward direction from the snapshot to an end point, causing generation of historical execution state at various points along the emulation of the application. The method further includes collecting the historical execution state. The method further includes using the collected historical execution state, emulating reverse execution of the application by substituting collected historical execution state, when needed, to restore previous state needed as a result of emulation of reverse execution of the application.

Reversible debugging in a runtime environment

Collecting runtime virtual machine external state for an application running in an application runtime virtual machine, for use in emulation of the application. A method includes identifying application bytecode for which runtime virtual machine external state is to be collected. The method further includes executing machine code generated from the bytecode to generate the runtime virtual machine external state. The method further includes collecting the runtime virtual machine external state. The method further includes storing the runtime virtual machine external state for use in emulating the application.

Collecting application state in a runtime environment for reversible debugging

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).

Dynamic diagnostic code instrumentation over a historic program execution

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.

Using historic execution data to visualize tracepoints

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.

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. Aspects of familiar compilers or familiar runtimes may be re-purposed for innovative execution control which replays previously generated native code, as opposed to their established purpose of generating native code.

Execution control with cross-level trace mapping

Presenting historical state associated with prior execution of an entity. Based on replaying segment(s) of execution of an entity based on a trace, embodiments could present an indication of whether a value of a code element is, at a first execution time point, unknown, known, previously known, and/or known in the future. Additionally, or alternatively, embodiments could present an indication of a value relied upon by simulated execution of a function at a second execution time point, along with an indication of a timing of knowledge of the value in relation to the second execution time point. Additionally, or alternatively, embodiments could present an indication that a return value of a function would be known if the function had executed at a third execution time point, or an indication that the return value would be unknown if the function had executed at the third execution time point.

Memory validity states in time-travel debugging

Growing community of inventors

Redmond, WA, United States of America

Patrick Nelson