An instrumentation overhead regulation technique regulates an amount of work performed by a client library of an investigative platform used to monitor, diagnose and solve errors associated with application development and production. The client library calculates processing resources utilized during its runtime activity to enable adjustment of the amount of work it performs based on the measured activity. An agent may determine the overhead activity impact to user application performance by monitoring processing resource metrics of the user application. The agent analyzes the calculated overhead and processing resource metrics to render decisions to automatically regulate the capture fidelity of the client library. Regulation of the capture fidelity may be implemented by modifying parameters of a dynamic configuration. If results of the analysis indicate a potential issue, the amount of work the client library performs may be trimmed to ensure that the calculated overhead of the client library and its impact on user application performance does not exceed a predetermined threshold.

A trace anomaly grouping and visualization technique logically groups traces with anomalies to cases to enable software developers to monitor, diagnose and visualize the anomalies, as well as to solve the anomalies during application development and production. A client library of an investigative platform collects signals from traces (trace signal information). The technique organizes (groups) related trace signals of methods with anomalies (e.g., exceptions, performance abnormalities such as slowness) into datasets (denominated as “cases”) based on common cause for an anomaly and correlates the signals to identify a case. The collected information may be used to differentiate between root causes of the anomalies using a comparative visualization of traces displayed on a standard user interface of the investigative platform. As such, the technique facilitates an understanding of differences among traces of executable code that resulted in the failure and traces without failure by providing the ability to comparatively examine views of those traces displayed on the standard UI. Signals of two or more traces may be selected and displayed side-by-side for comparison. The traces may be selected from a general notion of a healthy trace and a failed trace.

Embodiments of the present disclosure relate to methods, systems, and computer program products for monitoring a state of an application. A target object that is to be monitored in an application may be determined in response to receiving a monitoring configuration. A position of the target object in source codes of the application may be identified. A state of the target object may be monitored in response to the application being traced to a location corresponding to the position.

A tracing coprocessor that records execution trace data based on a cache coherency protocol (CCP) message. The tracing coprocessor comprises logic that causes the tracing coprocessor to listen on a bus that is communicatively coupled to a primary processor that executes executable code instructions. The logic also causes the tracing coprocessor to, based on listening on the bus, identify at least one CCP message relating to activity at a processor cache. The logic also causes the tracing coprocessor to identify, from the at least one CCP message, a memory cell consumption by the primary processor. The logic also causes the tracing coprocessor to initiate logging, into an execution trace, at least a memory cell data value consumed by the primary processor in connection with execution of at least one executable code instruction.

An apparatus includes a processor, a first interface configured to connect to a bus of the apparatus, a second interface configured to communicate over a packet network, and circuitry. The circuitry is configured to, in a first operational mode, exchange data between the processor and one or more remote devices over the packet network, via the second interface, and in a second operational mode, monitor the bus using the first interface, detect a predefined trigger event occurring on the bus and, in response to detecting the trigger event, log one or more transactions on the bus that are adjacent to the trigger event and generate one or more protocol-analysis packets comprising at least part of the logged transactions.

A user-annotated reference implementation identifies variable values generated by the reference implementation during its execution. A software implementation under analysis is executed. Variable values in the running memory of the program code of the software implementation under analysis, during its execution, are identified and copied. The variable values traced from the running memory of the program code are compared against the annotated variable values generated by the reference implementation, to determine a similarity between the program code under analysis, and the reference implementation. An output is generated that is indicative of whether the traced variables from the program code under analysis are the same as the annotated variable values generated by the reference implementation.

A method is disclosed. The method including receiving at a telemetry service a plurality of transaction responses from a plurality of components distributed across a network, wherein the plurality of transaction responses is generated to process a request originating from a source component, wherein the request includes a request identifier, wherein the plurality of transaction responses includes a plurality of code path identifiers. The method including generating a fingerprint associated with the request by concatenating the plurality of code path identifiers, wherein each transaction response includes the request identifier and a corresponding code path identifier. The method including storing the fingerprint in a data storage.

An in-circuit emulator device includes a CPU that executes a program, and outputs or inputs/outputs parameter values that change due to a program being executed, a plurality of trace memories that sequentially store the parameter values outputted by or inputted/outputted to/by the CPU to form a change history of the parameter values, an event detection circuit that detects a specific event that occurs as the CPU executes the program, and an event trace control circuit that stops a storage operation of any one of the plurality of trace memories in response to detection of the specific event by the event detection circuit, and reads and outputs the change history of the parameter value from the one trace memory.

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.

A non-transitory computer-readable recording medium storing an information processing program for causing a computer to execute a procedure, the procedure includes acquiring a start time and an end time of an event processed by a process forming software in which a fault has occurred from a storage, detecting any event in which a processing time is unusual, the any event being processed by any process forming the software, and identifying, when the any event is detected, a type of data related to the any process corresponding to cause of an unusual processing time of the detected any event, based on a state of the any process.