Class / Patent application number | Description | Number of patent applications / Date published |
714380110 | Memory dump | 33 |
20110093747 | DEBUGGING CLIENT-SIDE CODE - A method for debugging client-side code includes a client receiving an application file set from a server in response to the client requesting an application. A singleton is generated on the client by executing a script in the application file set. The singleton monitors a data event generated by an application programming interface. The singleton writes a client data record to a cache memory in response to the application programming interface generating the data event. The client data record records an application event. The singleton flushes the contents of the cached memory in response to a flush event, and transfers the contents to the server for persistent storage. | 04-21-2011 |
20110231710 | Mechanism for Saving Crash Dump Files of a Virtual Machine on a Designated Disk - A mechanism for saving crash dump files of a virtual machine (VM) on a designated disk is disclosed. A method of embodiments of the invention includes configuring an operating system (OS) of a VM managed by a hypervisor of a host machine to store any crash dump files created by the VM to a designated crash dump virtual disk associated with the VM but accessible outside of operations of the VM, determining that the VM experienced a crash event, stopping operations of the VM, and obtaining a crash dump file created by the VM that details the crash event from the designated crash dump virtual disk. | 09-22-2011 |
20120023373 | TESTING A SOFTWARE APPLICATION USED IN A DATABASE SYSTEM - A method for testing a software application used in a database system. The method includes receiving multiple changes to the software application, and running a plurality of tests on the software application. The method further includes determining if any of the tests fail, and if any of the tests fail, identifying which changes caused the failures. | 01-26-2012 |
20120036397 | UTILIZING LOG EVENT ONTOLOGY TO DELIVER USER ROLE SPECIFIC SOLUTIONS FOR PROBLEM DETERMINATION - A log event can be received from a log source within an application server environment. The log event can be an error message which is associated with a log level. In one embodiment, the application server environment can be a JAVA | 02-09-2012 |
20120124426 | DEBUGGING IN A CLUSTER PROCESSING NETWORK - A technology is described for debugging in a cluster processing network. A scheduler can dispatch a process that is part of the cluster job for execution. Further, a compute node can be used to execute the process dispatched by the scheduler to the compute node. A debugger can be activated in response to an unhandled suspension event in the process on the compute node. In addition, the debugger can send notification messages regarding the unhandled suspension event. A job monitor can receive a notification from the debugger that an unhandled suspension event has occurred. The notification can be displayed to a user via the job monitor. | 05-17-2012 |
20120179936 | EARLY COLLECTION OF DIAGNOSTIC INFORMATION - Generation of diagnostic information of a computer-implemented system is made early so that the data is closer to the causation of errors or for performance analysis. At least one selected activity of the system is monitored from initiation of the activity, and the monitoring is for successful completion. Early collection of diagnostic information is provided by comparing the time of the activity without successful completion to an initial trigger, where the initial trigger is less than the time period for a time-out for the activity. If the time of the activity without successful completion exceeds the initial trigger, diagnostic information is collected and an initial dump of the diagnostic information is taken. In one example, a notification that the dump of diagnostic information has been taken is directed to the host or diagnostic terminal. | 07-12-2012 |
20120254667 | PERFORMING NETWORK CORE DUMP WITHOUT DRIVERS - Core dump is performed over a network without relying on network device drivers. Instead of network device drivers, firmware of network devices that is typically used during boot is preserved in memory post-boot, and one or more application program interfaces of the firmware are invoked to perform the network core dump. For ease of implementation, a network bootstrap program that has standard application program interfaces for calling into the firmware of network devices may be invoked when performing core dump over the network. | 10-04-2012 |
20120304015 | GENERATING APPROPRIATELY SIZED CORE FILES USED IN DIAGNOSING APPLICATION CRASHES - A method, system and computer program product for generating appropriately sized core files used in diagnosing application crashes. An instruction pointer corresponding to the instruction that led to the application crash is identified. Address ranges of the garbage collection module and the compiler module are obtained. A determination is made as to whether the address of the instruction pointer lies within any of these address ranges for each stack frame in a crash stack. If it does not, then read or write instructions executed prior to the instruction that led to the application crash are identified for each stack frame in the crash stack. If a value of a register involved in such read or write instructions is within the address range of the compiled code buffers and/or heap, then the compiled code buffers and/or heap need to be included in the core file; otherwise, they do not. | 11-29-2012 |
20130145218 | Mechanism for Saving Crash Dump Files of a Virtual Machine on a Designated Disk - A method for saving crash dump files of a virtual machine (VM) on a designated disk is disclosed. The method includes associating, by a hypervisor that virtualizes a plurality of virtual machines (VMs), each VM of the plurality of VMs with a crash dump disk that is solely dedicated to the VM, wherein each crash dump disk is located separate from its associated VM. The method further includes configuring, by the hypervisor, an OS of each VM with a crash file path to the crash dump disk associated with the VM, and configuring, by the hypervisor, each VM of the plurality of VMs to generate crash dump files for the VM upon a crash event of the VM and store, via the crash file path, the generated crash dump files to the crash dump disk associated with the VM. | 06-06-2013 |
20130290790 | INFORMATION PROCESSING APPARATUS HAVING MEMORY DUMP FUNCTION, MEMORY DUMP METHOD, AND RECORDING MEDIUM - An information processing apparatus that executes an operating system, the apparatus including a panic process unit configured to stop the operating system when the operating system has detected an error, a mapping process unit configured to assign, to the operating system stopped by the panic process unit, a second memory area which is other than a first memory area being used by a kernel of the operating system before stop or by a hypervisor that controls the operating system before stop of the operating system, a reactivation process unit configured to reactivate the operating system by using the second memory area as a usage area, and a memory dump process unit configured to read data in the first memory area, and to write the data to a dump file after the operating system is reactivated. | 10-31-2013 |
20130339799 | METHOD AND SYSTEM FOR IDENTIFYING ERRORS IN CODE - A method for identifying errors in code is provided. The method may include rebuilding object dependencies from a heap dump, calculating memory usage of each object, identifying top consumers of memory by object class, analyzing how much memory each class consumes with respect to how much other classes consume, building a corpus of data that may be used in a progressive machine learning algorithm, and identifying suspect classes. Additionally, the suspect classes and the memory usage statistics of the suspect classes may then be used as an identifying signature of the associated out of memory error. The identifying signature of the associated out of memory error may then be used to compare with the signatures of other out of memory occurrences for identifying duplicate error occurrences. | 12-19-2013 |
20140019810 | METHOD OF ASCERTAINING PRIMARY CAUSE OF MEMORY CONSUMPTION IN PROGRAM, AND COMPUTER SYSTEM AND COMPUTER PROGRAM FOR THE SAME - A method of holding information for identifying a cause for an object becoming problematic and presenting the information to a user. The method ascertains the cause of memory consumption by a program in a computer system. This method includes: acquiring a first call path related to the creation of an object from a memory; acquiring a second call path related to the connection to the object from the memory; and determining a common part of the acquired first and second call paths, wherein the common part indicates the cause in the program. | 01-16-2014 |
20140040670 | INFORMATION PROCESSING DEVICE AND PROCESSING METHOD FOR INFORMATION PROCESSING DEVICE - An information processing device includes a memory, and a plurality of processors coupled to the memory and including cache memories, and configured to select a processor where a capacity of the cache memory is the smallest among the plurality of processors, the selected processor executes memory dump processing for the memory. | 02-06-2014 |
20140068341 | INTROSPECTION OF SOFTWARE PROGRAM COMPONENTS AND CONDITIONAL GENERATION OF MEMORY DUMP - An approach for introspection of a software component and generation of a conditional memory dump, a computing device executing an introspection program with respect to the software component is provided. An introspection system comprises one or more conditions for generating the conditional memory dump based on operations of the software component. In one aspect, a computing device detects, through an introspection program, whether the one or more conditions are satisfied by the software component based on information in an introspection analyzer of the introspection program. In addition, the computing device indicates, through the introspection program, if the one or more conditions are satisfied by the software component. In another aspect, responsive to the indication, the computing device generates the conditional memory dump through the introspection program. | 03-06-2014 |
20140129880 | GENERATION OF MEMORY DUMP OF A COMPUTER PROCESS WITHOUT TERMINATING THE COMPUTER PROCESS - In a computer system, a memory dump of a multi-threaded process can be created to contain information on all the threads without terminating the process, if the process uses user threads. | 05-08-2014 |
20140149799 | CREATING AN OPERATING SYSTEM DUMP - Creating an operating system dump. A main memory of a computer system is divided into at least three contiguous memory areas, comprising a primary memory area, a secondary memory area and a data memory area. A first instance of an OS (operating system) is booted into the main memory, a second instance of the operating system is loaded into the secondary memory area using the active first instance of the operating system, execution of the first active instance of the OS is stopped if a critical execution error occurs, and the computer system is re-started using the loaded second instance of the operating system which becomes the active instance of the OS. A dump of the primary memory area is created, and a third instance of the operating system is loaded into the primary memory area. | 05-29-2014 |
20140181593 | CORRELATION OF SOURCE CODE WITH SYSTEM DUMP INFORMATION - The present arrangements relate to analyzing a software error. At least one dump file created in response to a crash of software executing on a processing system can be accessed. Based on the dump file, a base version of at least one software module that was loaded when the crash occurred can be identified. Based on the dump file, maintenance that has been applied to the at least one software module also can be identified. A report recommending new corrective maintenance to be applied to the at least one software module can be generated. | 06-26-2014 |
20140258785 | IDENTIFYING A STORAGE LOCATION FOR A STORAGE ADDRESS REQUESTED DURING DEBUGGING - A method for identifying a storage location for a requested storage address. The method includes receiving a request to view data at a storage address and determining the requested storage address corresponding to a plurality of storage locations. The method includes determining whether the requested storage address identifies memory related to a dump file being analyzed by a dump formatter. Then, in response to determining the requested storage address identifies memory related to the dump file being analyzed by the dump formatter, the method includes identifying one of the plurality of storage locations. The method includes directing the request to the identified storage location. | 09-11-2014 |
20140372806 | VIRTUAL MACHINE SYSTEM AND INFORMATION STORING PROCESSING METHOD - A virtual machine system includes a first storage unit, a second storage unit, and a processor. The first storage unit includes a storage area allocated for a first virtual machine to operate. The second storage unit stores information stored in the first storage unit. The processor executes a process including detecting a failure of a first virtual machine, generating a second virtual machine when a failure of the first virtual machine is detected and making the second virtual machine perform storing information stored in the first storage unit into the second storage unit, and deleting the second virtual machine when the storing by the second virtual machine is completed. | 12-18-2014 |
20140380102 | Advancing and Rewinding a Replayed Program Execution - In an embodiment, a data processing system comprises a storage system coupled to a unit under test comprising a heap memory, a static memory and a stack; second logic operable to perform: detecting one or more changes in a first state of the heap memory and the static memory; storing, in the storage system, as a state point of the unit under test, the one or more changes in the first state of the heap memory and the static memory; third logic operable to perform: receiving a request to change the memory under test to a particular state point; in response to the request, loading the particular state point from the storage system and applying the particular state point to the heap memory and the static memory to result in changing the heap memory and the static memory to a second state that is substantially equivalent to the first state. | 12-25-2014 |
20150046754 | COMPUTER AND DUMPING CONTROL METHOD - A circuitry of a computer is configured to monitor an update state in a prescribed period of time of a plurality of units of management of data stored in the memory device for each of the plurality of units, to select a target unit as a target of dumping that outputs data from among the plurality of units on the basis of a monitoring result of the update state, and to dump data corresponding to the selected target unit. | 02-12-2015 |
20150052403 | Snapshotting Executing Code with a Modifiable Snapshot Definition - 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. | 02-19-2015 |
20150095710 | DEBUGGER TIMED THREAD RELEASE - A method for debugging a program having a plurality of threads includes identifying, for each thread, a target point at which the program terminated and a staging point previously executed in the thread. The method further includes executing each thread from the staging point to the target point and determining, for each thread, a staging time based upon the executing of each thread from the staging point to the target point. The method further includes executing each thread from its staging point based on the staging time of the thread so that the plurality of threads will reach the crash location at approximately the same time such that the program threads execute in a similar pattern to the execution that caused the crash. | 04-02-2015 |
20150127991 | Historical Software Diagnostics using Lightweight Process Snapshots - 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. | 05-07-2015 |
20150149830 | DATA DUMP FOR A MEMORY IN A DATA PROCESSING SYSTEM - As the file system of an operating system program might be damaged by a crash, the file system is usually used neither for the selection of data to be dumped from a memory nor for the analysis of the dumped data, and all data contained in one or several areas of the memory are dumped. In order to preserve the integrity of the file system and enable its use after the crash, the memory is divided into a primary and a secondary memory section during a memory setup, file system data are transferred from the primary memory section to the secondary memory section widely out of the control of the operating system program, and a read access of a dump program is directed to the secondary memory section in order to select file system data to be dumped after the crash using error data. | 05-28-2015 |
20150324246 | CORRELATION OF SOURCE CODE WITH SYSTEM DUMP INFORMATION - The present arrangements relate to analyzing a software error. At least one dump file created in response to a crash of software executing on a processing system can be accessed. Based on the dump file, a base version of at least one software module that was loaded when the crash occurred can be identified. Based on the dump file, maintenance that has been applied to the at least one software module also can be identified. A report recommending new corrective maintenance to be applied to the at least one software module can be generated. | 11-12-2015 |
20160034384 | SYSTEM AND METHOD FOR ALTERING FUNCTIONALITY OF AN APPLICATION - Disclosed are systems and methods for altering functionality of an application. An example method comprises updating the application, wherein the application includes one or more functional modules; detecting events occurring on the computer after the updating, wherein types of the detected events belong to a set of detectable events; determining which of the one or more functional modules of the application caused the detected events; and altering the one or more detected functional modules, wherein the altering of the functional modules and which functional modules are altered depend on the detected events and on which functional modules caused the detected events. | 02-04-2016 |
20160085656 | SYSTEM DIAGNOSTICS WITH THREAD DUMP ANALYSIS - A thread dump analysis tool analyzes a series of thread dumps and identifies one or more potential problems in the application from which the thread dumps were generated. Hints regarding the potential problems are presented. The hints can be generated based on relative values generated by analysis of sequential dumps. The hints may be hints that could not be generated by analysis of a single thread dump. Other hints may be hints that are enhanced by analysis of multiple thread dumps, whose importance is made clearer by appearance in multiple thread dumps, or that are unchanged in detection, importance, or both, by the use of multiple thread dumps. The hints can then be presented in order of importance. Additionally or alternatively, hints below a certain threshold of importance can be hidden. | 03-24-2016 |
20160085657 | Thread Dump Viewer - A thread dump viewer presents information for a plurality of threads. The information about the threads can be presented in a table view. The thread dump viewer can allow the user to expand a thread in the table view to see a stack trace for the thread. The stack trace may include information for objects that are associated with other threads. For example, the thread may be waiting on a lock object locked by another thread. The thread dump viewer can present information about the associated thread based on a user interaction. This process can be continued iteratively, allowing the stack traces of interrelated threads to be seen to arbitrary depths. | 03-24-2016 |
20160110238 | AUTOMATED DIAGNOSIS OF SOFTWARE CRASHES - A method for diagnosing software crashes includes retrieving a stack-trace from at least one of a new problem report, updated problem report, and authorized analysis report from a repository. A vector is automatically created from the retrieved stack-trace using the function name and associating the resultant vector with the problem report and authorized analysis reports. Vector space modeling is used to calculate the angles between the resultant vectors to determine similarities. Similar problem reports and authorized analysis reports are grouped into similar sets using a maximal cliques process. New software crashes are automatically diagnosed by extracting the stack-trace from a new problem report of the new software crash, and selecting a potential solution by searching the grouped problem reports and authorized analysis reports for a stack-trace similar to the new stack-trace. | 04-21-2016 |
20160110269 | Providing Supervisor Control Of Control Transfer Execution Profiling - In one embodiment, an apparatus includes a control transfer termination (CTT) state machine configured to raise a fault when an indirect control transfer instruction of a process is not terminated by a CTT instruction. A virtual machine monitor (VMM) is configured to selectively enable the CTT state machine for the process. In addition, a binary translation engine is configured to receive fault information associated with a fault raised by the CTT state machine, provide at least some of the fault information to a security agent associated with the process, and responsive to direction from the security agent, to translate a code block of the process to a translated code block including a first CTT instruction associated with the indirect control transfer instruction, such that when the translated code block including the indirect control transfer instruction and the first CTT instruction is to be executed, the CTT state machine will not raise a fault. Other embodiments are described and claimed. | 04-21-2016 |
20160154696 | FIRMWARE DUMP COLLECTION FROM PRIMARY SYSTEM DUMP DEVICE ADAPTER | 06-02-2016 |
20160179606 | SYSTEM AND METHOD FOR PROVIDING A WATCHDOG TIMER TO ENABLE COLLECTION OF CRASH DATA | 06-23-2016 |