The present invention relates generally to storing information for use in debugging computer software. More particularly, the invention provides a method and apparatus for using a serial bus, such as an IEEE 1394 bus, to remotely create, from a host computer, a snapshot of physical memory of a target computer.
Many operating systems support xe2x80x9ccrash dumpsxe2x80x9d or xe2x80x9ccore dumps.xe2x80x9d These are typically files that an operating system generates when the operating system recognizes an internal failure. Operating systems typically switch to a minimal mode of operation and attempt to save the operating system""s state information to a file on disk. A software developer or system administrator can subsequently use the saved state information to analyze the operating system failure. Such analysis is often referred to as xe2x80x9cdebugging.xe2x80x9d
Typically, a crash dump file is generated by the operating system and stored on a disk drive that is local to the computer on which the internal failure occurred. FIG. 2 is a simplified state diagram showing that upon the occurrence of an internal failure, a state transition 202 occurs from normal operation state 200 to minimal mode of operation state 204 in which a crash dump file is stored locally, for instance on a local hard disk.
Unfortunately, upon the occurrence of an internal failure, for various reasons the operating system may not be able to store the crash dump file locally. For instance, there may be insufficient local storage space available or the target computer""s local hard drive might be off line.
Under such circumstance, it is typically desirable to retrieve the crash dump remotely and store it on a remote computer the moment the target computer crashes. Due to the relatively slow rate at which conventional serial buses transfer data, however, transferring the contents of physical memory of a target computer, for instance 64 megabytes of memory, would take a prohibitively long time.
Accordingly, there is a need for improved techniques for creating a crash dump file much more quickly, while minimizing the amount of operating system state information that is corrupted or otherwise lost, and under circumstances in which a crash dump file cannot be stored on a local drive of the computer that has experienced an internal fault.
Referring to FIG. 3, techniques for remote debugging of the kernel of an operating system and application programs of a first computer, such as target computer 300, from a second computer, such as host computer 302 are known in the art. In such an environment, a hardware link 304 (e.g., RS-232C), such as a serial connection, is used to transmit debugging commands to and return debugging results from software undergoing test on target computer 300, via serial ports 306 and 308. A small portion of core operating system (xe2x80x9cO.S.xe2x80x9d) 310, typically xe2x80x9cpushesxe2x80x9d data to host debugger 312, thus using processor time on target computer 300 and causing side effects on target computer 300 that would not occur absent debugging-related operation of this small portion of core O.S. code.
Kernel debugging presents technical problems different than those presented by debugging application programs 314, which typically run in user mode. For instance, core operating system 310 typically must be halted for kernel debugging, but core operating system 310 typically is not halted for debugging of user mode application programs.
FIG. 4 is a flow chart of simplified steps for conventional remote debugging of core operating system 310, which typically runs in kernel mode. At step 400, a user, such as a system administrator, issues a command through host debugger 312 to break execution, in other words stop, suspend, or halt, execution of target computer 300. At step 402, the system administrator may issue well-known debugging commands to step through portions of code, set the contents of target computer memory locations to specific values, and the like. Debugging in this manner is often a very time-consuming process. At step 404, a determination is made regarding whether the system administrator is finished debugging the core operating system 310 of target computer 300. Steps 402 and 404 continue in a loop until the system administrator is finished remotely debugging the kernel of target system 300, at which point host computer debugger 312 releases control of core 0.S. 310, which may resume executing, as indicated at step 406.
A significant disadvantage of conventional remote kernel debugging in accordance with FIGS. 3 and 4 is that target computer 300 is not operating while the kernel is being remotely debugged. Because debugging is often necessary for certain types of software issues, such as memory leaks, application hangs, and many other non-fatal crashes, and because debugging is typically very time-consuming, there is a need for improved remote kernel debugging techniques that allow debugging to be performed in parallel with operation of a target computer.
A system and method in accordance with certain inventive principles overcomes the foregoing shortcomings of conventional generation of crash dump files and remote kernel debugging. In accordance with principles of the invention, a two-computer crash dump scenario is provided in which a snapshot of the physical memory of a target computer is extracted and stored by a host computer over a serial bus, which may be IEEE 1394 compliant. In this manner, a crash dump can be transferred quickly and under circumstances in which a conventional single computer crash dump may not be feasible.
A host computer debugger may remotely issue a command to stop execution of the core operating system of the target computer. Handshake information is then preferably provided from the target computer core operating system to the host computer debugger. The handshake information preferably specifies, among other information, one or more address ranges at which physical memory is present on the target computer, as disclosed in the commonly assigned patent application entitled xe2x80x9cMethod and Apparatus for Remotely Debugging Computer Software Over a Serial Bus,xe2x80x9d application Ser. No. 09/488,015, filed Jan. 20, 2000, which is incorporated herein by reference.
The host computer debugger then preferably directly accesses the physical memory of the target computer system over the serial bus in accordance with the handshake information. The host computer then stores the contents of the physical memory of the target computer system.
Execution of the core operating system of the target system may then be resumed, and the core operating system of the target computer may be debugged in parallel with resumed execution of the target computer core operating system. In this manner, the amount of time that the target system computer is not operational due to debugging is significantly reduced relative to debugging the core operating system of the target computer in real time.
Additional features and advantages of the invention will be apparent upon reviewing the following detailed description.