Abstract: Embodiments improve software defect diagnosis. Analytic focus is automatically walked back from an initial symptomatic diagnostic context to a previous diagnostic context that is closer to underlying causes. Diagnosis may obtain diagnostic artifacts such as traces or dumps, extract diagnostic context, decompile executables, lookup likely causes based on symptoms, scan logs, and submit diagnostic context to software analysis services. An analysis service may perform static analysis, security testing, symptom-pair lookups, or antipattern scanning, for example, and may include a neural network or other machine learning model, for example. Root causes are culled from analysis results and identified to a software developer. Changes to mitigate the defect's impact are suggested in some cases. Thus, the software developer receives debugging leads without manually navigating through all the tool interfaces or unrelated details of diagnostic contexts.

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: Embodiments improve software defect diagnosis. Analytic focus is automatically walked back from an initial symptomatic diagnostic context to a previous diagnostic context that is closer to underlying causes. Diagnosis may obtain diagnostic artifacts such as traces or dumps, extract diagnostic context, decompile executables, lookup likely causes based on symptoms, scan logs, and submit diagnostic context to software analysis services. An analysis service may perform static analysis, security testing, symptom-pair lookups, or antipattern scanning, for example, and may include a neural network or other machine learning model, for example. Root causes are culled from analysis results and identified to a software developer. Changes to mitigate the defect's impact are suggested in some cases. Thus, the software developer receives debugging leads without manually navigating through all the tool interfaces or unrelated details of diagnostic contexts.

Abstract: Embodiments provide improved diagnosis of software defects. Static analysis services and other source-based diagnostic tools and techniques are applied even when the source code underlying software is unavailable. Diagnosis obtains diagnostic artifacts, extracts diagnostic context from the artifacts, decompiles to get source, and submits decompiled source to a source-based software analysis service. The analysis service may be a static analysis tool, an antipattern scanner, or a machine learning model trained on source code, for example. The diagnostic context may also guide the analysis, e.g., by localizing decompilation or prioritizing possible causes. Likely causes are culled from analysis results and identified to a software developer. Changes to mitigate the defect's impact are suggested. Thus, the software developer receives debugging leads without providing source code for the defective program, and without manually navigating through a decompiler and through the analysis services.

Abstract: A debugging and diagnostics system allow for dynamic code generation that inserts code into a production application to identify snappoints that cause snapshots to be taken if predefined conditionals are satisfied. The snappoints are associated with locations in source code for the production application and include conditional statements that must be met to create a snapshot of the production application. The snappoints are used to generate a collection plan that is provided to the server running the production application. The server rewrites the code of the production application based upon the collection plan to insert instructions that create snapshots when the conditional statements are met.

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: A debugging and diagnostics system allow for dynamic code generation that inserts code into a production application to identify snappoints or breakpoints that cause snapshots to be taken if predefined conditionals are satisfied. The snappoints are associated with locations in source code for the production application and include conditional statements that must be met to create a snapshot of the production application. The snappoints are used to generate a collection plan that is provided to the server running the production application. The server rewrites the code of the production application based upon the collection plan to insert instructions that create snapshots when the conditional statements are met.

Abstract: A debugging and diagnostics system allow for dynamic code generation that inserts code into a production application to identify snappoints that cause snapshots to be taken if predefined conditionals are satisfied. The snappoints are associated with locations in source code for the production application and include conditional statements that must be met to create a snapshot of the production application. The snappoints are used to generate a collection plan that is provided to the server running the production application. The server rewrites the code of the production application based upon the collection plan to insert instructions that create snapshots when the conditional statements are met.

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

Abstract: Systems and methods for processing breakpoints on a remotely located server computer are presented. In one embodiment, a breakpoint is set in a target program. This includes setting the breakpoint in a manner that does not block execution of the target program upon the breakpoint triggering. Additionally, executable instructions are included at the location in the target program of the breakpoint to generate a snapshot of debugger information regarding the target program. The snapshot information is then provided to a programmer's debugger for debugging purposes. Further, in setting the breakpoint, the breakpoint is conditioned by the programmer to trigger only upon the satisfaction of a set of conditional criteria corresponding to a logical execution context.

Abstract: Described technologies extend the information available from an execution trace of a program by providing heuristically-derived values for memory contents when the trace does not include data expressly showing the value of a memory cell at a particular execution time. Various heuristics are described. The heuristics may use information about the memory cell at other times to produce the derived value. Some heuristics use other trace data, such as whether the memory cell is in a stack, whether there are gaps in the trace, or whether garbage collection or compilation occurred near the time in question. Grounds for the derived value are reported along with the derived value. A time-travel debugger or other program analysis tool can then present the derived values to users, or make other use of the derived values and grounds to assist debugging and other efforts to improve the functioning of a computing system.

Abstract: Systems and methods for processing breakpoints in a target program executing on a remotely located server computer are presented. In one embodiment, upon receiving instructions to set a breakpoint in a target program, a code block of the target program is identified in which the execution location of the breakpoint is to be set. The identified code block of the target program is re-compiled. Re-compiling the code block of the target program comprises re-compiling the code block without optimizations and including executable instructions at the execution location of the breakpoint to generate a snapshot of debugger information regarding the target program upon the breakpoint triggering. The re-compiled code block is then bound in the target program.

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.

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: Described technologies extend the information available from an execution trace of a program by providing heuristically-derived values for memory contents when the trace does not include data expressly showing the value of a memory cell at a particular execution time. Various heuristics are described. The heuristics may use information about the memory cell at other times to produce the derived value. Some heuristics use other trace data, such as whether the memory cell is in a stack, whether there are gaps in the trace, or whether garbage collection or compilation occurred near the time in question. Grounds for the derived value are reported along with the derived value. A time-travel debugger or other program analysis tool can then present the derived values to users, or make other use of the derived values and grounds to assist debugging and other efforts to improve the functioning of a computing system.

Abstract: A diagnostic workflow file can be used to control the future diagnostic actions taken by a debugger without user interaction with the debugger when it executes. The diagnostic workflow file is used by a debugger during a debug session. The debugger performs the actions directed by the diagnostic workflow file to simulate an interactive live debug session. The diagnostic workflow file can include conditional diagnostic operations whose execution depends on the state of program variables, diagnostic variables and diagnostic primitives in the debug session.

Abstract: A debugging and diagnostics system allows users to take lightweight process snapshots of running debuggee processes so the users may analyze those snapshots at a later time. The snapshot mechanism allows debugging tools to compare an original process or one or more process snapshots or to compare any of a series of snapshots to each other. The snapshot mechanism further allows users to inspect a snapshot of process memory while allowing the original process to continue running with minimal impact. A user may do historical debugging using process snapshots of a debuggee process taken over time. This allows the user to view the state of the debuggee process as it existed when the snapshot was taken. The lightweight process snapshot is less invasive because it does not require a full copy of the memory and allows the original process to run un-interrupted while specific collections and inspections are completed.

Abstract: A debugging and diagnostics system allow allow for dynamic code generation that inserts code into a production application to identify snappoints or breakpoints that cause snapshots to be taken if predefined conditionals are satisfied. The snappoints are associated with locations in source code for the production application and include conditional statements that must be met to create a snapshot of the production application. The snappoints are used to generate a collection plan that is provided to the server running the production application. The server rewrites the code of the production application based upon the collection plan to insert instructions that create snapshots when the conditional statements are met.

Abstract: A debugging and diagnostics system allow for dynamic code generation that inserts code into a production application to identify snappoints or breakpoints that cause snapshots to be taken if predefined conditionals are satisfied. The snappoints are associated with locations in source code for the production application and include conditional statements that must be met to create a snapshot of the production application. The snappoints are used to generate a collection plan that is provided to the server running the production application. The server rewrites the code of the production application based upon the collection plan to insert instructions that create snapshots when the conditional statements are met.