EP3036636A1 - Snapshotting executing code with a modifiable snapshot definition - Google Patents
Snapshotting executing code with a modifiable snapshot definitionInfo
- Publication number
- EP3036636A1 EP3036636A1 EP14837230.3A EP14837230A EP3036636A1 EP 3036636 A1 EP3036636 A1 EP 3036636A1 EP 14837230 A EP14837230 A EP 14837230A EP 3036636 A1 EP3036636 A1 EP 3036636A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- snapshot
- application
- instance
- definition
- condition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/323—Visualisation of programs or trace data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
Definitions
- Crash dumps are datasets that may be collected when a computer program encounters an error for which the computer can no longer function.
- Operating systems and other software management products may collect data at a catastrophic failure so that a programmer may be able to detect the cause of the failure. The programmer may then be able to recreate the error or make changes that may prevent the error from occurring again.
- a tracing and debugging system may take a snapshot of an application in response to an event, and may continue executing the program after the snapshot is captured.
- the snapshot may be stored and retrieved later in a debugging tool where a programmer may browse the snapshot or the snapshot may have some other analysis performed.
- the snapshot may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata.
- the snapshot may be defined in a snapshot configuration that may include an event description and data to be collected.
- a tracing and debugging system may collect both performance related tracer data and snapshot data.
- the tracer data may contain aggregated performance and operational data, while the snapshot data may contain call stack, source code, and other information that may be useful for debugging and detailed understanding of an application.
- the snapshot data may be stored in a separate database from the tracer data, as the snapshot data may contain data that may be private or sensitive, while the tracer data may be aggregated information that may be less sensitive.
- a debugging user interface may be used to access, display, and browse the stored snapshot data.
- a debugging system may display snapshot information that may be collected in response to an event identified while an application executes.
- the debugging system may allow a user to browse the various data elements in the snapshot, and may allow the user to modify a snapshot configuration by including or excluding various data elements within the snapshot data.
- the user interface may have a mechanism for including or excluding data elements that may be presented during browsing, as well as options to change the events that may trigger a snapshot.
- the updated snapshot configuration may be saved for future execution when the event conditions are satisfied.
- FIGURE 1 is a diagram illustration of an embodiment showing a system for snapshot debugging.
- FIGURE 2 is a diagram illustration of an embodiment showing a network environment with devices that may collect and view snapshots.
- FIGURE 3 is a diagram illustration of an embodiment showing a combined performance monitoring and snapshot gathering system.
- FIGURE 4 is a diagram illustration of an embodiment showing an example user interface for a debug viewer.
- FIGURE 5 is a flowchart illustration of an embodiment showing a method for collecting snapshot instances.
- FIGURE 6 is a flowchart illustration of an embodiment showing a method for inserting snapshot code in an application.
- FIGURE 7 is a flowchart illustration of an embodiment showing a more detailed method for collecting snapshot instances.
- FIGURE 8 is a flowchart illustration of an embodiment showing a method for wrapping function with snapshot code.
- FIGURE 9 is a flowchart illustration of an embodiment showing a method for a snapshot use cycle.
- FIGURE 10 is a flowchart illustration of an embodiment showing a method for viewing a snapshot instance.
- a snapshot debugging system may take snapshots of an application in response to an event, and store the snapshots for later viewing.
- the snapshots may occur as an application executes, and may collect various program state at the designated events.
- the program state may include local and global variable values, call stacks, source code related to the executing code, and other information.
- a debugging interface may be used to view, browse, or otherwise inspect the contents of each snapshot.
- the snapshots may be relatively lightweight glimpses of the program as each event is detected.
- a programmer may define snapshots for conditions where problems may have occurred in the past, and the snapshots may allow the programmer the ability to look back to the program state at the time of the event to determine the causes and effects of the monitored event.
- the snapshot mechanism may be deployed in several manners.
- a programmer may manually insert snapshot code into an application.
- the snapshot code may include conditions that, when satisfied, cause a snapshot to be taken.
- the snapshot code may be deployed by monitoring the application code at runtime.
- a monitoring agent may check for the snapshot conditions. When the conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data, and cause the application to resume execution.
- implementation may be deployed in conjunction with a monitoring system that may wrap function calls or provide some other performance monitoring.
- the snapshots may be edited and modified.
- the snapshot may include a definition of the event that may trigger a snapshot to be taken, as well as a definition of the data to be collected.
- the triggering event definition may be defined using any type of expression, event, or other information, and may be evaluated at runtime.
- the data collection definition may define the type of data to collect, as well as values from local and global variables, metadata, external events, or other information.
- the snapshots may include executable code that may be executed as part of the data collection process.
- the snapshots may be viewed using a viewing or browsing user interface.
- the snapshots may be viewed in a debugging user interface, which may also serve as part of a real time debugger.
- Such embodiments may view the stored snapshots as instances of the real time debugger that are recalled from the point the snapshots were taken.
- the user interaction with the snapshots may be similar to the user interaction with a real time debugger, but may lack the ability to step forward or backwards through the code like a real time debugger.
- the snapshot debugging system may be a lightweight data collection system that may gather program state at various events.
- the data collection may be lightweight in the sense that an application may be paused for a short period of time, then continue execution. Such data collection may give a programmer some insight into what occurs around specific events, so that the programmer may be better able to improve or modify the application.
- a tracing and snapshot debugging may integrate continuous performance measurements and snapshots to better understand a computer application's behavior.
- the performance measurement system may monitor an application on a periodic basis, and may be a platform on which snapshots of the program state may be taken.
- the performance measurement system may monitor an application by different mechanisms, such as instrumenting the application, monitoring an execution environment in which an application runs, or other mechanisms. While the monitoring is ongoing, a snapshot manager may detect conditions for snapshots and may cause a snapshot to be taken and stored.
- the performance measurements may be aggregations of performance metrics, such as counters or other summary metrics, while the snapshots may contain actual data that may be handled or processed by an application.
- the snapshots may contain sensitive data and the snapshots may be stored in a separate storage repository than performance metrics, which may contain less sensitive information.
- some or all of the snapshot data may be encrypted.
- a debugging user interface may be used for viewing and browsing snapshot instances.
- the debugging user interface may have a similar user experience as when the same interface may be used for real time debugging, however the data being displayed may be retrieved from a storage repository for the snapshots as opposed to retrieving data from a live execution environment in the case of real time debugging.
- a user may be able to create or modify a snapshot definition for deploying future snapshots.
- a snapshot may contain a subset of an application's state at the time a snapshot is taken.
- the user may be able to add the object to future snapshots.
- the user may be able to drag and drop, right click, or perform some other interaction in the user interface to select the object for inclusion or exclusion from the snapshot.
- the snapshot may be deployed to collect data while an application executes.
- profiler refers to any mechanism that may collect data when an application is executed.
- instrumentation may refer to stubs, hooks, or other data collection mechanisms that may be inserted into executable code and thereby change the executable code
- profiler or “tracer” may classically refer to data collection mechanisms that may not change the executable code.
- data collection using a "tracer” may be performed using non-contact data collection in the classic sense of a “tracer” as well as data collection using the classic definition of
- instrumentation where the executable code may be changed.
- data collected through “instrumentation” may include data collection using non-contact data collection mechanisms.
- instrumentation may include any type of data that may be collected, including performance related data such as processing times, throughput, performance counters, and the like.
- the collected data may include function names, parameters passed, memory object names and contents, messages passed, message contents, registry settings, register contents, error flags, interrupts, or any other parameter or other collectable data regarding an application being traced.
- execution environment may be used to refer to any type of supporting software used to execute an application.
- An example of an execution environment is an operating system.
- an "execution environment” may be shown separately from an operating system. This may be to illustrate a virtual machine, such as a process virtual machine, that provides various support functions for an application.
- a virtual machine may be a system virtual machine that may include its own internal operating system and may simulate an entire computer system.
- execution environment includes operating systems and other systems that may or may not have readily identifiable “virtual machines” or other supporting software.
- an application is used to refer to any combination of software and hardware products that may perform a desired function.
- an application may be a single software program that operates with a hardware platform.
- Some applications may use multiple software components, each of which may be written in a different language or may execute within different hardware or software execution environments. In some cases, such applications may be dispersed across multiple devices and may use software and hardware components that may be connected by a network or other communications system.
- references to "a processor” include multiple processors. In some cases, a process that may be performed by “a processor” may be actually performed by multiple processors on the same device or on different devices. For the purposes of this specification and claims, any reference to “a processor” shall include multiple processors which may be on the same device or different devices, unless expressly specified otherwise.
- the subject matter may be embodied as devices, systems, methods, and/or computer program products. Accordingly, some or all of the subject matter may be embodied in hardware and/or in software (including firmware, resident software, micro-code, state machines, gate arrays, etc.) Furthermore, the subject matter may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system.
- a computer-usable or computer- readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
- the computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.
- computer readable media may comprise computer storage media and communication media.
- Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
- Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an instruction execution system.
- the computer-usable or computer-readable medium could be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, of otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
- the embodiment may comprise program modules, executed by one or more systems, computers, or other devices.
- program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
- functionality of the program modules may be combined or distributed as desired in various embodiments.
- Figure 1 is an illustration of an example embodiment 100 showing a system for snapshot debugging.
- Embodiment 100 is an example of various components that may interact to collect snapshot data when conditions for the snapshot are met, then store the snapshots to be viewed by a debug viewer.
- the snapshots may capture application state in response to some condition or event being detected.
- the snapshot system may collect application state, such as call stack information and values for selected variables.
- the snapshot may capture a glimpse of the application at a specific event or condition, and may help a programmer understand an application's behavior.
- the snapshot system may collect snapshots that may be viewed and browsed later. Such a system may be used to collect data over time.
- a programmer may have a bug or other anomaly that may be difficult to reproduce.
- the programmer may create one or several snapshots that may be taken under conditions similar to the anomaly.
- the programmer may launch the snapshots and let the application run, so that the snapshots collect program state when the anomaly occurs.
- the programmer may come back after a period of time and view the snapshot datasets to help understand the application's state at the time of the anomaly.
- the user interface for viewing, browsing, and exploring the snapshots may be similar to a debugging user interface.
- a debugging user interface an application's source code may be displayed along with local and global variable values.
- the programmer may explore a snapshot using the same user interface as the programmer would use to explore a running application in debugging mode.
- a snapshot definition 102 may contain an event description 104 and a data definition 106.
- the event description 104 may be a condition under which the snapshot may be taken, and the data definition 106 may define the data to be collected.
- the event description 104 may include any type of expression for defining an event.
- the expression may use external information, such as a specific time of day or when a hardware interrupt may be raised.
- the expression may include complex expressions that may be evaluated at runtime to determine whether or not to take a snapshot.
- take a snapshot is used to denote a process of collecting state information in response to an event.
- the state information may be collected while an application is paused.
- snapshot data collection code may be inserted into an application, which may effectively pause the application while the snapshot data collection code executes and collects various application state.
- the processing of an application may be paused within and operating system or other execution environment, and a separate process may collect the application state during the pause.
- the data definition 106 may define the data to collect. Some embodiments may have a default data collection setting that may be varied by including or excluding elements from the default setting. In many cases, the data definition may include a call stack, which may include application code currently being executed, plus each call frame of higher level functions back to an outer loop or main level of an application.
- a call stack may be a data structure that stores information about active subroutines of an application.
- the call stack may be known as an execution stack, control stack, run-time stack, machine stack, or other nomenclature.
- the call stack may define a point to which a subroutine may return when it has finished execution.
- Some call stacks may store data for local variables at each call frame of the stack, as well as parameters that may be passed to and from subroutines.
- the data definition 106 may include complex memory objects that may be defined in a hierarchical structure.
- such memory objects may be collected by unpacking the structure at different levels.
- a default setting may unpack and collect complex memory objects at a first level, such that the first level values of the data structure may be captured and saved in the snapshot definition.
- Some data definition settings may cause such complex memory objects to be collected in their entirety, or at various levels within the data structure's hierarchy.
- a specific sub-object, value, or set of values may be defined for collection.
- the data definition 106 may include various metadata relating to the snapshot.
- metadata may include external information about the computer system on which the application is executing, such as the processor type and speed, memory and storage capacities and availabilities, hardware and software
- Metadata may also include timestamps, performance information, or other metadata.
- the snapshot definitions 102 may be consumed by a snapshot monitoring agent 108, which may cause snapshot data to be collected when the event described in an event description 104 may occur.
- the snapshot monitoring agent 108 may be deployed in several different forms.
- the snapshot code may be executable code that may collect data and transmit the data to a snapshot repository.
- the executable code may be include a call to a debugging application programming interface 112 to collect call stack information, metadata, variable values, and other information.
- the executable code may also include a call to a collection application programming interface which may receive the data, perform some processing and packaging of the data, and cause the snapshot instance to be stored.
- snapshot code may be inserted into an application automatically.
- the snapshot code may be inserted prior to runtime by automatically traversing the application code to identify conditions for which a snapshot may be taken. Such insertion may occur prior to runtime by analyzing source code or intermediate code, determining an appropriate location, and adding snapshot code that may evaluate the event description and, when the event conditions are satisfied, cause a snapshot to be taken.
- Some embodiments may insert snapshot code into an application at runtime.
- a monitoring system may wrap various functions for performance monitoring. The monitoring system may be detect that a condition for a snapshot may be present, and may cause the snapshot code to be inserted.
- a monitoring agent may monitor a running application, detect that the event conditions are satisfied, and cause the application to pause.
- Some such systems may deploy the monitoring agent as a separate thread or process than the application which is being monitored.
- Some such systems may use monitoring mechanisms that may be part of an operating system or execution environment to monitor the application as it executes.
- the execution environment 110 may execute an application 114 from which snapshots may be taken.
- the execution environment 110 may be an operating system, process virtual machine, system virtual machine, or other construct that may manage the execution of the application 114.
- the application 114 may be any type of computer program.
- the application 114 may be written in any computer language, from high level languages with complex frameworks to binary executable code. In some cases, the application may be compiled prior to execution, while in other cases, the application may be interpreted at runtime.
- Snapshot instances 116 may be generated at each event.
- the snapshot instances 116 may include call stack 118, local variables 120, global or shared variables 122, and source code 124 as well as other data and metadata.
- the snapshot monitoring agent 108 may be able to collect source code for each call frame.
- a snapshot instance 116 may include pointers to locations in source code in some embodiments. Such pointers may reference source code 128 which may be stored in a source code repository 126. When the source code may be displayed while viewing a snapshot instance, the source code may be retrieved from the source code repository 126
- a debug viewer 130 may display snapshot instances.
- the debug viewer 130 may be a full-fledged debugging system that may be able to execute code in a user interface and have functions for pausing execution, examining variables, setting breakpoints, stepping through executable code, and other functions.
- Such systems may also include editors, compilers, and other components.
- the debug viewer 130 may present the snapshot information using the same user interface as the debugging system but may retrieve the underlying data from a stored snapshot rather from an execution environment in which the application may be executing.
- the debug viewer 130 may be any type of interface through which a snapshot instance may be viewed.
- the user interface may present a subset of the snapshot instance 116 and a user may explore or browse different portions of the user interface to uncover and view various data.
- the debug viewer 130 may have capabilities to create and edit snapshot definitions.
- a user may be able to identify conditions or breakpoints for snapshot collection, as well as include or exclude various data elements for collection.
- the updated or newly created snapshots may be deployed for execution when the application 114 is executed in the future.
- Figure 2 is a diagram of an embodiment 200 showing components that may collect and view snapshot instances when an application is executed.
- the example of embodiment 200 is merely one example of a multi-device system that may generate and view snapshot instanced.
- Other architectures may include single device and multiple device architectures.
- the architecture of embodiment 200 includes a device 202 on which the snapshots may be collected, as well as several other devices for storing different elements of the snapshot. A last device may view the snapshot instances. In other embodiments, some or all of the functions illustrated may be combined into one or more devices.
- the diagram of Figure 2 illustrates functional components of a system.
- the component may be a hardware component, a software component, or a combination of hardware and software.
- Some of the components may be application level software, while other components may be execution environment level components.
- the connection of one component to another may be a close connection where two or more components are operating on a single hardware platform. In other cases, the connections may be made over network connections spanning long distances.
- Each embodiment may use different hardware, software, and interconnection architectures to achieve the functions described.
- Embodiment 200 illustrates a device 202 that may have a hardware platform 204 and various software components.
- the device 202 as illustrated represents a conventional computing device, although other embodiments may have different configurations, architectures, or components.
- the device 202 may be a server computer. In some embodiments, the device 202 may still also be a desktop computer, laptop computer, netbook computer, tablet or slate computer, wireless handset, cellular telephone, game console or any other type of computing device.
- the hardware platform 204 may include a processor 208, random access memory 210, and nonvolatile storage 212.
- the hardware platform 204 may also include a user interface 214 and network interface 216.
- the random access memory 210 may be storage that contains data objects and executable code that can be quickly accessed by the processors 208.
- the random access memory 210 may have a high-speed bus connecting the memory 210 to the processors 208.
- the nonvolatile storage 212 may be storage that persists after the device 202 is shut down.
- the nonvolatile storage 212 may be any type of storage device, including hard disk, solid state memory devices, magnetic tape, optical storage, or other type of storage.
- the nonvolatile storage 212 may be read only or read/write capable.
- the nonvolatile storage 212 may be cloud based, network storage, or other storage that may be accessed over a network connection.
- the user interface 214 may be any type of hardware capable of displaying output and receiving input from a user.
- the output display may be a graphical display monitor, although output devices may include lights and other visual output, audio output, kinetic actuator output, as well as other output devices.
- Conventional input devices may include keyboards and pointing devices such as a mouse, stylus, trackball, or other pointing device.
- Other input devices may include various sensors, including biometric input devices, audio and video input devices, and other sensors.
- the network interface 216 may be any type of connection to another computer.
- the network interface 216 may be a wired Ethernet connection.
- Other embodiments may include wired or wireless connections over various communication protocols.
- the software components 206 may include an operating system 218 on which various software components and services may operate.
- the application 236 may be executed in an operating system 218 or in an execution environment 222.
- the operating system 218 and execution environments 222 may have debugging application programming interfaces 220 and 224, respectively.
- a set of snapshot definitions 232 may define conditions for taking snapshots.
- a snapshot and monitoring agent 230 may perform dual roles of monitoring and managing snapshot collection. During execution of the application 236, the snapshot and monitoring agent 230 may detect that a condition for a snapshot has been satisfied, then collect various data elements as defined in the snapshot definition 232.
- the snapshots may be taken by calling debugging application programming interfaces 220 or 224.
- the debugging application programming interfaces may respond to requests to collect various program state, such as the call stack, local and global variables, and other information.
- the executing source code may also be retrieved in this manner.
- the snapshots may be encrypted prior to being stored.
- An encryption module 234 may encrypt some or all of the snapshot prior to transmitting the snapshot over a network 238 to a snapshot storage system 246.
- Some snapshots may contain sensitive or other information that may have an obligation for control and security. For example, an application that may process credit card numbers, personally identifiable information, or other sensitive information may have such information gathered in a snapshot. To prevent such data from being viewed or accessed, the snapshot be encrypted at the point of creation. The snapshot may be decrypted by an authorized user when using a debug viewer.
- the encryption module 234 may use any type of encryption or obfuscation mechanism to protect the contents of a snapshot instance.
- a public/private key system may be used, while in other cases some type of substitution cypher, dictionary, or other mechanism may be used to remove or obfuscate any sensitive information.
- Some embodiments may selectively apply encryption or obfuscation mechanisms.
- a snapshot instance may encrypt of obfuscate all data values for variables but may leave other data in the snapshot instance in plain text.
- a snapshot definition may include indicators for selectively encrypting or obfuscating different data elements within the snapshot instance.
- the network 238 may connect various devices together.
- the network 238 may be a local area network, wide area network, or any other communications network.
- a performance storage system 240 may collect and store performance data collected during execution of the application 236.
- the performance storage system 240 may include a hardware platform 242, which may be similar to the hardware platform 204.
- a performance database 244 may store the various performance information datasets collected by the snapshot and monitoring agent 230.
- a snapshot storage system 246 may collect and store snapshot instance data.
- the snapshot storage system 246 may have a hardware platform 248, which may be similar to the hardware platform 204.
- a snapshot instance database 250 may store the individual snapshot instances.
- different security policies may be applied to the performance data and snapshot data collected from an application.
- the performance data may be aggregated data that may include function names but may not include underlying data handled by the application.
- the snapshot data may include sensitive data that may have a more restrictive security policy applied.
- the security policies may be applied by having different storage systems for performance and snapshot data, where the snapshot data may be stored and managed with a more restrictive security policy.
- a restrictive security policy may dictate physical security, encryption settings, network configuration, access restrictions, or other configurations in order to limit access and protect data from unauthorized access.
- a source code storage system 252 may store and retrieve application source code.
- the source code storage system 252 may have a hardware platform 254, which may be similar to the hardware platform 204.
- Some such systems may include version management systems that may save different versions of source code.
- a snapshot may be created with a link or descriptor to the specific version of the application that may be executing.
- Such systems may retrieve the specified version of the application source code when displaying the snapshot instance in a debugging viewer.
- a debugging system 258 may be a system on which a programmer may view the snapshot instances among other functions.
- the debugging system 258 may operate on a hardware platform 260, which may be similar to the hardware platform 204.
- a debug viewer 262 may be an application that may display snapshot instances.
- the debug viewer 262 may be an interactive application that may allow a programmer to interact with the snapshot instances in a similar manner as a debugger.
- the debug viewer 262 may be a standalone application, may be an interactive page rendered in a browser, or may have some other architecture.
- the debugging system 258 may have a decryption module 264, which may decrypt the data encrypted by the encryption module 234 when the snapshot instance was created.
- Figure 3 is a diagram illustration of an embodiment 300 showing a combined performance monitoring and snapshot gathering system.
- Embodiment 300 illustrates functional components of a system that may apply performance or monitoring wrappers to functions, and may also insert snapshot code at runtime.
- Embodiment 300 may illustrate one example of a system that may wrap various functions for performance monitoring or tracing.
- the wrappers may gather and store performance information for each wrapped function, and the performance information may be stored for analysis or potentially displayed in real time.
- the wrapping function may be one mechanism whereby the conditions for a snapshot may be evaluated with each function call. When the conditions may be present, the wrapping system may insert snapshot code into the wrapped function or into the wrapper to cause a snapshot to be taken.
- the snapshot code may include code that may evaluate the additional conditions which, when met, may cause the snapshot to be evaluated.
- the snapshot code may be inserted into a function and one or more additional conditions may not be met, causing the snapshot to not be taken.
- the structure of the executable code representing a snapshot may include a set of conditions and a mechanism for gathering and storing snapshot data. Such an embodiment may be inserted into an application such that the application halts other processing and executes the snapshot code.
- the conditions may be expressed as executable code that contains a full set or subset of conditions, and the executable code may be evaluated at the point of taking a snapshot. When all of the conditions are met, the snapshot executable code that gathers snapshot information may then be executed.
- Dynamic languages may be a loose classification of programming languages that refer to those computer languages that may have mechanisms for modifying the application after compile time. Such actions may include adding new code, extending objects and definitions, modifying the type system, and other changes. Static languages may be able to perform such operations in some cases, but may typically not contain explicit features for doing so. Examples of dynamic programming languages are ActionScript, Clojure, Common Lisp, JavaScript, Perl, PHP, Python, R, Ruby, Smalltalk, and others.
- a system may receive application code 302.
- the application code 302 may contain several functions, with a current function identified by an execution pointer 304. As each function is identified for execution, a performance monitor with snapshot manager 306 may process the function.
- the incoming function may be wrapped using a wrapper function 308.
- the wrapper function 308 may contain monitoring mechanisms that collect performance and operational data, which may be used to monitor or display performance or operational characteristics of the application.
- a snapshot evaluator 310 may scan through one or more snapshot definitions 312 to determine whether or not a condition for a snapshot may be met by the function or within the function.
- the snapshot evaluator 310 may insert snapshot code into the function or wrapper.
- the snapshot code may include additional conditions that may be evaluated during execution.
- a function 316 may be created with a performance monitoring wrapper 314.
- the wrapped function may be executed by an execution engine 324, and the wrapper may output performance data 326 for analysis.
- a wrapper may be created around the function 320, and snapshot code 322 may be inserted into the function 320.
- the snapshot code 322 may be part of the wrapper 318 and may be executed before or after the function 320.
- the wrapped function 320 may be executed by the execution engine 324, with the wrapper 318 generating performance data 326 and the snapshot code 322 generating snapshot instances 328.
- Embodiment 300 is merely one mechanism for deploying snapshots that may be useful with dynamic languages. Other embodiments may have different logic or may deploy snapshots in different manners using dynamic or static programming languages.
- Figure 4 is an example illustration of an embodiment 400 showing a user interface 402 that may display snapshot information to a user.
- the user may be able to browse the contents of a snapshot, as well as create or modify a snapshot.
- the user interface 402 is merely one example of such a user interface.
- the user interface 402 may allow a programmer to browse source code and the state of an application at the point a snapshot was taken.
- the programmer may be able to view the call stack, the source code at each level of the call stack, and values of variables.
- the programmer may be able to modify existing snapshots or create new snapshots for later execution.
- a timeline 404 may present both performance data and snapshot instances.
- the top portion of the timeline may contain various performance indicators 406, while the bottom portion of the timeline may include snapshot indicators 408.
- Each of the snapshot indicators 408 may represent a single snapshot.
- the timeline 404 may be an interactive mechanism for viewing performance information that may have been collected over a period of time, along with the presence of snapshots that may have been taken during the same time period.
- a user may be able to select various elements of the timeline to view underlying data. For example, a user may click on one of the performance indicators 406 to view performance data collected during the representative time period.
- a selected snapshot 410 may cause the user interface 402 to be populated as illustrated.
- the selected snapshot 410 may represent a specific snapshot that a user wishes to view, and the selection may cause the snapshot to be retrieved from storage and displayed in the user interface 402.
- a code window 412 may display the source code of the application at the point of a snapshot.
- the source code may initially be displayed at the location that the snapshot was taken, and the user may be able to traverse up the call stack to view source code at locations where the various functions in the call stack were called.
- the source code may be contained in the snapshot definition, while in other embodiments, a snapshot may contain pointers or other links to the source code. Snapshots that store source code may be useful in systems where the source code may be changing rapidly, such as in development environments. In such systems, the entire source code of an application may not be available for browsing, as the snapshot may only contain source code in the vicinity of the functions in the call stack.
- a breakpoint indicator 414 may signify the location in the source code where a snapshot was taken.
- the code in the code window 412 may be the code in the vicinity of the breakpoint, and the user may be able to scroll up or down in the code window 412 to view more.
- the variables in the code window 412 may be interactive elements.
- a selected variable 416 may be highlighted. A user may select such a variable by clicking, right clicking, or perform some other action to indicate and select the variable. While the variable is selected, the user may be able to view the current value of the variable, as well as use the variable to define a breakpoint, add or remove the breakpoint from data collection, and other uses.
- the selected variable 416 may be highlighted by the user interface when the value for the selected variable is known.
- a call stack view 418 may serve as both a tool to view variable values as well as a code navigation tool.
- the call stack view 418 may show each function called as a subroutine to a top level function.
- the call stack view is interactive, a user may be able to select and expand a particular frame in the call stack.
- An expansion of a call stack frame may present the local variables for the expanded level of the call stack.
- the frame "main” is shown in a collapsed view, while the frame “initialize_server” is shown in an expanded view 422.
- the expanded view 422 local variables 424 are shown.
- the call stack view 418 may be used to navigate the source code.
- the selection of a specific call stack frame may cause the code window 412 to be updated with the source code in the vicinity of the subroutine call represented by the call stack frame.
- Other data 426 may be displayed as part of a snapshot view.
- the other data 426 may be metadata, external data, or other information that may be collected along with the snapshot.
- a breakpoint definition 428 may define the conditions under which the snapshot was collected. In the example of embodiment 400, the snapshot was taken when the incoming data object was "ping", the day of the week was not Monday, and the value of memory was greater or equal to 900MB.
- the breakpoint definition 428 may be an interactive window where a programmer may be able to add, remove, or modify the conditions for the snapshot.
- the data collection definition 430 may define the data to be collected. In many cases, a snapshot system may have a default set of data that may be collected. In such cases, the data collection definition 430 may define changes to the default settings by adding or removing values to be collected. In many cases, the data collection definition 430 may include metadata or other information that may be outside the normal scope of a snapshot.
- the programmer may launch the snapshot for future data collection by using the launch button 432. By launching the snapshot, future execution of the application may be done with the new snapshot definition.
- a set of navigation buttons may be used to navigate through the various snapshots.
- a previous button 434 and next button 438 may be actuated to select the previous and next snapshots, respectively.
- the snapshot may be displayed in the user interface 402.
- An identifier 436 may display the date and time of the current snapshot for the user's reference.
- FIG. 5 is a flowchart illustration of an embodiment 500 showing a method for collecting snapshot instances.
- the operations within a user interface 502 are illustrated in the left hand column, operations within a snapshot monitor 504 are illustrated in the center column, and operations within an execution environment 506 are illustrated in the right hand column.
- Embodiment 500 illustrates a general method that shows snapshot deployment and data collection.
- a user may create snapshot definitions using a user interface 502, then the snapshot definitions may be deployed to a snapshot monitor 504.
- the snapshot monitor 504 may cause the snapshots to be deployed and collect snapshot instances by working in conjunction with an execution environment 506.
- the method of embodiment 500 is a general method that may be deployed using several different types of mechanisms.
- a programmer may manually insert snapshot code in an application.
- the snapshot code may be inserted in an application before or during execution.
- a snapshot monitor 504 may be a separate process that may interact with an execution environment 506 but may not change the application code.
- snapshot conditions may be defined in block 508 and stored in block 510.
- the snapshot conditions may include both conditions for executing the snapshot and the data to be collected.
- the snapshot definition may be transmitted in block 512 to the snapshot monitor 504, which may receive the snapshot definition in block 514.
- the execution environment 506 may receive an application in block 518 and begin execution in block 520. While the application executes in block 522, the snapshot monitor 504 may monitor the execution in block 516.
- the snapshot monitor 504 may check to determine whether or not the conditions for the snapshot have been met in block 524. When the conditions have not been met, the process may return to block 516.
- the snapshot monitor 504 may cause the application to pause execution in block 526, which may be transmitted to the execution environment 506 where the execution may be paused in block 528.
- the snapshot monitor 504 may gather data defined in the snapshot definition in block 530. Part of the data gathering may include transmitting a request to the execution environment 506, which may be received in block 532. The execution environment 506 may gather the requested data in block 534 and transmit the data to the snapshot monitor 504 in block 538.
- a typical debugging application programming interface may be able to retrieve a call stack as well as local, global, and other variables.
- the data may be received by the snapshot monitor 504 in block 538. Additional state and metadata may be collected in block 540 while the application may be paused, after which the snapshot monitor 504 may cause the application to resume in block 542.
- the execution environment 506 may receive the resume request in block 544 and resume execution in block 546. The process of the execution environment may return to block 522 to continue execution.
- the snapshot monitor 504 may optionally encrypt the snapshot data in block 548 before storing the snapshot instance in block 550. In some
- certain portions or subsets of the snapshot data may be encrypted.
- Figure 6 is a flowchart illustration of an embodiment 600 showing a simplified method for inserting snapshot code into an application.
- the method of embodiment 600 may be a manual or automated method that may modify an application's code by inserting snapshot code in locations where a snapshot may be taken.
- Snapshot code may consist of a set of conditions for collecting a snapshot along with code for collecting and storing snapshot data as snapshot instances.
- the application in effect stops execution until the snapshot code has completed, then the application may resume processing.
- the source code may be received in block 602. Each location within the source code for a snapshot may be identified in block 604.
- Each of the locations may be processed in block 606.
- a condition for the snapshot may be defined in block 608.
- An expression defining the condition may be created in block 610.
- the expression may be executable code in the same language as the application.
- the snapshot code may be defined in a high level programming language that may have been used for the application. In other embodiments, the snapshot code may be defined using intermediate code, machine language, or in a different language than the main application. [00143] The snapshot code may be inserted into the application in block 612. In some embodiments, a snapshot may call various application programming interfaces that may gather, process, and store snapshot instances.
- the updated source code may be stored in block 614 and executed in block 616.
- Embodiment 600 may be implemented in a manual method by a programmer.
- the programmer may manually identify the locations for snapshots and insert code for each snapshot.
- the method may be implemented in an automated fashion. Some embodiments may process source code for an application to automatically scan for locations in the source code for snapshots, then automatically insert snapshot code. Such automated systems may insert snapshot code in source code, which may be subsequently compiled or interpreted. In some cases, the automated systems may insert snapshot code in intermediate code form, which may be subsequently compiled in a just in time compiler prior to execution, or may be interpreted in intermediate form.
- the method of embodiment 600 places snapshot code at predefined locations within the application. Such an embodiment may infer that one of the conditions for a snapshot may be execution of the application to the location of the snapshot code.
- Figure 7 is a flowchart illustration of an embodiment 700 showing a more detailed method for collecting snapshot instances.
- Embodiment 700 illustrates one example of the data that may be collected in a snapshot, along with an example method for how these data may be collected.
- Embodiment 700 may illustrate the data collection performed by for a snapshot instance. In some cases, the operations of embodiment 700 may be embodied in executable code that may be inserted in an application.
- Snapshot code may be launched in block 702.
- the call stack may be retrieved in block 704.
- the call stack may have multiple frames, each of which may define a calling function that calls a subroutine.
- Many computer languages may have a notion of a call stack, although some languages may use different nomenclature and some programming
- Each frame of the call stack may be processed in block 706.
- For each frame, local variables for the frame may be retrieved in block 708.
- Values of parameters passed to the called function may be retrieved in block 710.
- a snapshot may include source code for the application.
- the source code in the vicinity of the breakpoint or calling routine may be captured in block 714.
- pointers to locations in the source code may be identified in block 716.
- Some embodiments unpack various memory objects, which may be defined in various complex structures, an example of which may be hierarchical structure. Such memory objects may be identified in block 718 and processed in block 720.
- the first level of data values may be retrieved in block 722. If another level is to be retrieved in block 724, the additional level may be retrieved in block 726. When all of the levels have been retrieved that were requested in block 724, the process may return to block 720 to process another memory object.
- a user may be able to select the amount of data to collect.
- Part of such a definition may include defining a portion or all of a complex data object to collect. Some data objects may be very large and cause a large amount of data to be collected in a snapshot. When all of such data may not be useful, a subset may be collected.
- Metadata may be collected in block 728.
- the metadata may be various data that may not be retrievable from the call stack and various memory objects.
- metadata may include timestamps, external events, hardware interrupt states, hardware and software configurations, performance metrics, or other information.
- the snapshot data may be formatted in block 730 and encryption may be applied in block 732.
- the snapshot may be transmitted to storage in block 734 and the snapshot code may end in block 736.
- Figure 8 is a flowchart illustration of an embodiment 800 showing a method for wrapping functions with snapshot code.
- Embodiment 800 illustrates one example of a mechanism to deploy snapshot code, and one which may be automated.
- the method of embodiment 800 may be incorporated into a monitoring system that may wrap functions for performance monitoring.
- Embodiment 800 may illustrate a mechanism that may integrate performance monitoring and snapshot gathering in a single system.
- the performance monitoring may operate by wrapping all or selected functions with a performance monitoring function that may gather operational data about an application. As each function may be evaluated for monitoring, an additional analysis may determine whether or not the conditions for a snapshot may be met by the function. If so, the system may add snapshot code to the function or the wrapper to collect snapshot data.
- An application may begin execution in block 802.
- the application may have multiple functions that may be executed as part of the application.
- the functions may be subroutines or other blocks of executable code.
- a function may be received in block 804.
- An analysis may begin in block 806 to evaluate each of the snapshot definitions to the current state of the application. For each snapshot definition, an analysis may determine if a snapshot condition may apply to the function in block 808. If not, the snapshot is skipped and the process may return to block 806. If so, a snapshot condition expression may be created in block 810 and snapshot code may be inserted into the function or wrapper in block 812.
- the analysis of block 808 may attempt to identify whether or not any snapshot definition may apply to the function about to be executed.
- the analysis may be an initial determination that a snapshot may be performed in a function, then additional conditions may be added to the snapshot code, so that the snapshot may be executed only when the full set of conditions may be satisfied.
- a performance monitoring wrapper may be created in block 814 and the function to be executed may be wrapped in the performance monitoring wrapper in block 816.
- the snapshot code may be inserted into the executable code of the function. In other cases, the snapshot code may be inserted into the wrapper. When the snapshot code is part of the wrapper, the snapshot code may be configured to execute prior to executing the function or after the function has completed.
- the wrapped function may be executed in block 818 and
- performance data may be collected in block 820. Snapshot instances may be collected in block 822.
- Figure 9 is a flowchart illustration of an embodiment 900 showing a lifecycle of a snapshot.
- Embodiment 900 shows snapshot collection and snapshot use, and shows various use scenarios for snapshots.
- Embodiment 900 shows a simplified method for snapshot instance collection and viewing.
- a programmer may create one or more snapshot definitions which may be run against an application. While the application executes, snapshots may be collected. At a later time, the programmer may use a debug viewer to browse each snapshot instance to determine what may have been happening with the application at the time of each snapshot instance.
- snapshot definitions may be identified. As an application executes in block 904 and a snapshot condition is met in block 906, the program state or a subset of program state may be collected in block 908. The snapshot instance may be stored in block 910. If execution is ongoing in block 912, the process may return to block 904. When execution ends in block 912, the application may end in block 914.
- the steps from 902 through 914 may reflect the data gathering phase, where snapshot instances may be collected during application execution.
- the following steps may reflect the activities that may be performed to view and browse the information contained in the snapshot instance.
- a debugging interface may be launched in block 916.
- One example of such an interface may be found in embodiment 400, although other configurations may also be used.
- a snapshot instance may be selected in block 918.
- the snapshot data may be viewed and browsed in block 920.
- performance data may be viewed and browsed in block 922.
- the debug interface may include a code viewer and code editor. When an editor is present, the programmer may update or modify the source code using the editor in block 924.
- the process may loop back to block 918.
- the application may be compiled in block 928 and the process may loop back to block 904.
- FIG 10 is a flowchart illustration of an embodiment 1000 showing a method for viewing a snapshot instance.
- Embodiment 1000 may be a simplified example of some of the operations of a debug interface that may display and interact with a snapshot instance.
- the example of embodiment 1000 illustrates an example of a debug interface where source code may be retrieved from a repository that may be separate from the snapshot instance.
- the [00180] may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions.
- various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.
- Embodiment 1000 is a simplified example of a process that may be performed by a debug interface.
- the process of embodiment 1000 is quite linear, however many of the interactive features of a debug interface may happen in different sequences or may occur in parallel with other operations.
- a debug interface may be launched.
- a snapshot instance may be retrieved in block 1004. From the snapshot instance, links or pointers to the source code may be identified in block 1006. The source code may be retrieved from a source code repository in block 1008.
- a view of the snapshot may be selected in block 1010.
- the code associated with the deepest level of the call stack may be selected as the first view.
- the source code associated with the view may be displayed in block 1012.
- Local variables may be displayed in block 1014 and global variables may be displayed in block 1016.
- the call stack may be displayed in block 1018. At this point, a user may be able to browse through the data.
- the user may identify a variable to add to the snapshot definition in block 1020 and may modify the condition under which the snapshot may be taken in block 1022.
- the changes in blocks 1020 and 1022 may update the snapshot definition.
- the updated snapshot definition may be deployed to cause future snapshot instances to be collected.
- the process may return to block 1010.
- Another view of the snapshot may be requested when a user selects another frame on a call stack, for example.
- the updated snapshot definition may be stored in block 1026.
- the process may return to block 1004, otherwise the process may end in block 1030.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Data Mining & Analysis (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
Claims
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/970,302 US9465721B2 (en) | 2013-08-19 | 2013-08-19 | Snapshotting executing code with a modifiable snapshot definition |
US13/970,319 US9021444B2 (en) | 2013-08-19 | 2013-08-19 | Combined performance tracer and snapshot debugging system |
US13/970,343 US20150052400A1 (en) | 2013-08-19 | 2013-08-19 | Breakpoint Setting Through a Debugger User Interface |
PCT/US2014/011932 WO2015026391A1 (en) | 2013-08-19 | 2014-01-16 | Snapshotting executing code with a modifiable snapshot definition |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3036636A1 true EP3036636A1 (en) | 2016-06-29 |
EP3036636A4 EP3036636A4 (en) | 2017-06-21 |
Family
ID=52484025
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14837230.3A Withdrawn EP3036636A4 (en) | 2013-08-19 | 2014-01-16 | Snapshotting executing code with a modifiable snapshot definition |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3036636A4 (en) |
CN (1) | CN105723346A (en) |
WO (1) | WO2015026391A1 (en) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3235549A1 (en) * | 2016-04-21 | 2017-10-25 | KooJoo Ltd | Gameplay trigger detection |
CN106557352B (en) * | 2016-10-17 | 2019-08-09 | 北京轩宇信息技术有限公司 | A method of realizing the two-way execution of instruction set simulator forward and reverse |
CN107315685A (en) * | 2017-06-28 | 2017-11-03 | 青岛东联信息科技有限公司 | A kind of real-time adjustment method of non-invasive procedure |
CN107577798B (en) * | 2017-09-20 | 2021-01-22 | 苏州浪潮智能科技有限公司 | Snapshot creating method and device and computer readable storage medium |
CN109542779A (en) * | 2018-11-12 | 2019-03-29 | 泰康保险集团股份有限公司 | Test method, device and storage medium |
CN110515831A (en) * | 2019-07-15 | 2019-11-29 | 平安普惠企业管理有限公司 | Breakpoint debugging method, debugging system, computer equipment and computer storage medium |
US11188364B1 (en) * | 2020-08-28 | 2021-11-30 | International Business Machines Corporation | Compilation strategy for a sharable application snapshot |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050149809A1 (en) * | 2003-12-10 | 2005-07-07 | International Business Machines Corporation | Real time determination of application problems, using a lightweight diagnostic tracer |
US20050273757A1 (en) * | 2004-06-07 | 2005-12-08 | Anderson Craig D | Methods, systems, and computer program products for summarizing operational behavior of a computer program |
US8024292B2 (en) * | 2005-06-29 | 2011-09-20 | Emc Corporation | Creation of a single snapshot using a server job request |
US7627728B1 (en) * | 2005-12-29 | 2009-12-01 | Symantec Operating Corporation | System and method for efficient generation of application snapshots |
CN101295279B (en) * | 2007-04-29 | 2012-05-09 | 国际商业机器公司 | Method and system for debugging program in multi-threading surroundings |
ATE525694T1 (en) * | 2009-07-27 | 2011-10-15 | Ibm | METHOD AND SYSTEM FOR STORING THE OPERATING STATE OF RUNNING APPLICATIONS IN THE EVENT OF UNEXPECTED SHUTDOWN EVENTS |
US8595709B2 (en) * | 2009-12-10 | 2013-11-26 | Microsoft Corporation | Building an application call graph from multiple sources |
US9645913B2 (en) * | 2011-08-03 | 2017-05-09 | Daniel Geist | Method and apparatus for debugging programs |
-
2014
- 2014-01-16 CN CN201480046188.1A patent/CN105723346A/en active Pending
- 2014-01-16 WO PCT/US2014/011932 patent/WO2015026391A1/en active Application Filing
- 2014-01-16 EP EP14837230.3A patent/EP3036636A4/en not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
See references of WO2015026391A1 * |
Also Published As
Publication number | Publication date |
---|---|
EP3036636A4 (en) | 2017-06-21 |
WO2015026391A1 (en) | 2015-02-26 |
CN105723346A (en) | 2016-06-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9465721B2 (en) | Snapshotting executing code with a modifiable snapshot definition | |
US9021444B2 (en) | Combined performance tracer and snapshot debugging system | |
US10050797B2 (en) | Inserting snapshot code into an application | |
US10621068B2 (en) | Software code debugger for quick detection of error root causes | |
US11494287B2 (en) | Scalable execution tracing for large program codebases | |
EP3765964B1 (en) | Protecting sensitive information in time travel trace debugging | |
EP3036636A1 (en) | Snapshotting executing code with a modifiable snapshot definition | |
EP3213217B1 (en) | Historical control flow visualization in production diagnostics | |
US10802946B2 (en) | Presenting differences between code entity invocations | |
Chow et al. | Multi-stage replay with crosscut | |
US10956304B2 (en) | Dynamic diagnostic code instrumentation over a historic program execution | |
US11321220B2 (en) | Cross-thread memory indexing in time-travel debugging traces | |
WO2020163119A1 (en) | Using historic execution data to visualize tracepoints | |
EP4207713A1 (en) | Method and system for event based, privacy aware capturing of partial screen changes for devices with restricted resources | |
US11068378B2 (en) | Memory value exposure in time-travel debugging traces | |
US20110099329A1 (en) | Analysis and timeline visualization of storage channels | |
LU500190B1 (en) | Payload data removal from execution traces | |
LU500189B1 (en) | Using entropy to prevent inclusion of payload data in code execution log data | |
Miller | Trace visualization for security analysis |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20160315 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAX | Request for extension of the european patent (deleted) | ||
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 11/34 20060101ALN20170214BHEP Ipc: G06F 11/36 20060101AFI20170214BHEP |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20170524 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 11/34 20060101ALN20170518BHEP Ipc: G06F 11/36 20060101AFI20170518BHEP |
|
17Q | First examination report despatched |
Effective date: 20190531 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 11/34 20060101ALN20190725BHEP Ipc: G06F 11/36 20060101AFI20190725BHEP |
|
INTG | Intention to grant announced |
Effective date: 20190805 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 11/34 20060101ALN20190726BHEP Ipc: G06F 11/36 20060101AFI20190726BHEP |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20191217 |