CA2420008C - Panic message analyzer - Google Patents
Panic message analyzer Download PDFInfo
- Publication number
- CA2420008C CA2420008C CA2420008A CA2420008A CA2420008C CA 2420008 C CA2420008 C CA 2420008C CA 2420008 A CA2420008 A CA 2420008A CA 2420008 A CA2420008 A CA 2420008A CA 2420008 C CA2420008 C CA 2420008C
- Authority
- CA
- Canada
- Prior art keywords
- bug
- core dump
- panic message
- panic
- message
- 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.)
- Expired - Fee Related
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
- G06F11/366—Software debugging using diagnostics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2294—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by remote test
-
- 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/324—Display of status information
- G06F11/327—Alarm or error message display
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
- Information Transfer Between Computers (AREA)
- Automatic Analysis And Handling Materials Therefor (AREA)
Abstract
The invention provides a method and system for automatically obtaining and analyzing error messages from end users of software and hardware products.
Additionally, the invention provides a method and system of providing solutions that automatically and manually correct the errors. An ever-growing database of errors and solutions is maintained so that future identical or similar problems are expedited without human intervention. Successful analysis at any but the lowest level automatically allows previous levels to be taught greater efficiency for future analysis of the same or similar errors.
Additionally, the invention provides a method and system of providing solutions that automatically and manually correct the errors. An ever-growing database of errors and solutions is maintained so that future identical or similar problems are expedited without human intervention. Successful analysis at any but the lowest level automatically allows previous levels to be taught greater efficiency for future analysis of the same or similar errors.
Description
PANIC MESSAGE ANALYZER
Background of the Invention 1. Field of the invention This invention relates to analysis of panic messages from network servers.
Background of the Invention 1. Field of the invention This invention relates to analysis of panic messages from network servers.
2. Related Art Computers rely on programmed instructions to direct their operation. General purpose computers most often receive these instructions from software that executes within their memory. Despite the fact that software engineers vigorously test programs to eliminate the presence of coded instructions that may cause errors (commonly known as bugs), the presence of bugs is practically unavoidable in simple programs and a foregone conclusion in complex programs.
When a computer executes a program instruction that causes an error, the error may have relatively no effect on the system, or the error may cause the system to crash.
All errors are of importance to software engineers, however, those that cause a catastrophic result, such as a crash, are of primary importance. Generally, systems are designed to provide an alert to a system operator that they have suffered some type of failure. Error messages provide this alert, and these messages are useful when reporting errors to a manufacturer of the software.
A first known method to enable reporting of a software application error is to provide a pre-public release of a software package to a select group customers for "beta testing." During this trial period, customers report to the company any problems that they encounter and the software engineers at the company fix the bugs and provide updated versions of the software to the beta testers who continue testing with the new version. This process continues for a short testing period until the software is hopefully error free.
While this first known method provides reporting of software bugs to a manufacturer it suffers from several drawbacks. First, it provides no method for automatically reporting the problem to the manufacturer. It relies solely on the beta tester to inform the manufacturer. Second, it provides no automated analysis of a problem identified by a beta tester. That is, it requires an employee at the manufacturer to determine whether the problem has already been reported, fixed, or is a new problem. Third, it provides no method for delivery of updated software to a user who is determined to be using older software with an identified and fixed problem.
A second known method of reporting computer system errors is to rely on the end user to call the manufacturer and report a problem when it occurs. The customer is provided a customer support line that they may call to report problems they are having.
Based on the frequency and subject matter of calls received, the manufacturer may conclude there is a problem with some portion of a program.
While this second known method provides reporting of software bugs to a manufacturer it suffers from several drawbacks. First, the customer may decide not to call as customer support calls tend to involve long waits on hold listening to musak and often provides no relief as the manufacturer has no formal structure in place to coordinate and analyze the calls they receive. Second, the customer may not be knowledgeable enough to provide the manufacturer with the necessary information they need to diagnose the problem, or worse, they may misinform the manufacturer as to the origin of the problem.
Accordingly, it would be advantageous to provide a method for computer system errors to be reliably reported to a manufacturer in such a manner that the process is automated to the level of determining whether the problem is known or unknown.
And, if the problem is known, providing channels for delivery of updated software to clients, and if unknown, providing a method to obtain and analyze necessary information from the suspect system to enable diagnosis and correction of the errors.
Summary of the Invention The invention includes a system and method for analyzing panic messages from computer systems that have suffered failures. One of the last processes a filer (server dedicated to file storage and retrieval) performs before it crashes is to render a panic message. This message is indicative of the problem that caused the filer to crash. This message is sent to the manufacturer via a communications network such as the Internet. The message also includes other information, such as the user's name, the version of the software, a back trace, and a mini core dump.
At the manufacturer, automatic analysis commences to determine if the bug can be identified. First, the panic message is analyzed by comparing it against a database of panic messages that correspond with known bugs. If successful, automated housekeeping occurs which includes updating this instance in a tracking database, delivery of an answer to the customer (including solutions), updating analysis statistics, and additional activities. If unsuccessful the process continues.
Second, a back trace analyzer analyzes the back trace using an expression algorithm that looks for exact matches on function names and recognized sequences of matches that correspond to known bugs. If successful, automated housekeeping occurs as indicated above. If unsuccessful, the process continues.
Third, a core script analyzer analyzes a core dump for recognizable patterns of code that correspond to known bugs. If successful, automated housekeeping occurs as indicated above If unsuccessful the process continues.
Fourth, if the automated methods above fail to identify the problem as a known bug, the core in manually analyzed to detect known and unknown bugs.
Manual and automatic housekeeping is performed following this manual analysis.
Brief Description of the Drawings Figure 1 illustrates a block diagram of a system for a panic message analyzer.
When a computer executes a program instruction that causes an error, the error may have relatively no effect on the system, or the error may cause the system to crash.
All errors are of importance to software engineers, however, those that cause a catastrophic result, such as a crash, are of primary importance. Generally, systems are designed to provide an alert to a system operator that they have suffered some type of failure. Error messages provide this alert, and these messages are useful when reporting errors to a manufacturer of the software.
A first known method to enable reporting of a software application error is to provide a pre-public release of a software package to a select group customers for "beta testing." During this trial period, customers report to the company any problems that they encounter and the software engineers at the company fix the bugs and provide updated versions of the software to the beta testers who continue testing with the new version. This process continues for a short testing period until the software is hopefully error free.
While this first known method provides reporting of software bugs to a manufacturer it suffers from several drawbacks. First, it provides no method for automatically reporting the problem to the manufacturer. It relies solely on the beta tester to inform the manufacturer. Second, it provides no automated analysis of a problem identified by a beta tester. That is, it requires an employee at the manufacturer to determine whether the problem has already been reported, fixed, or is a new problem. Third, it provides no method for delivery of updated software to a user who is determined to be using older software with an identified and fixed problem.
A second known method of reporting computer system errors is to rely on the end user to call the manufacturer and report a problem when it occurs. The customer is provided a customer support line that they may call to report problems they are having.
Based on the frequency and subject matter of calls received, the manufacturer may conclude there is a problem with some portion of a program.
While this second known method provides reporting of software bugs to a manufacturer it suffers from several drawbacks. First, the customer may decide not to call as customer support calls tend to involve long waits on hold listening to musak and often provides no relief as the manufacturer has no formal structure in place to coordinate and analyze the calls they receive. Second, the customer may not be knowledgeable enough to provide the manufacturer with the necessary information they need to diagnose the problem, or worse, they may misinform the manufacturer as to the origin of the problem.
Accordingly, it would be advantageous to provide a method for computer system errors to be reliably reported to a manufacturer in such a manner that the process is automated to the level of determining whether the problem is known or unknown.
And, if the problem is known, providing channels for delivery of updated software to clients, and if unknown, providing a method to obtain and analyze necessary information from the suspect system to enable diagnosis and correction of the errors.
Summary of the Invention The invention includes a system and method for analyzing panic messages from computer systems that have suffered failures. One of the last processes a filer (server dedicated to file storage and retrieval) performs before it crashes is to render a panic message. This message is indicative of the problem that caused the filer to crash. This message is sent to the manufacturer via a communications network such as the Internet. The message also includes other information, such as the user's name, the version of the software, a back trace, and a mini core dump.
At the manufacturer, automatic analysis commences to determine if the bug can be identified. First, the panic message is analyzed by comparing it against a database of panic messages that correspond with known bugs. If successful, automated housekeeping occurs which includes updating this instance in a tracking database, delivery of an answer to the customer (including solutions), updating analysis statistics, and additional activities. If unsuccessful the process continues.
Second, a back trace analyzer analyzes the back trace using an expression algorithm that looks for exact matches on function names and recognized sequences of matches that correspond to known bugs. If successful, automated housekeeping occurs as indicated above. If unsuccessful, the process continues.
Third, a core script analyzer analyzes a core dump for recognizable patterns of code that correspond to known bugs. If successful, automated housekeeping occurs as indicated above If unsuccessful the process continues.
Fourth, if the automated methods above fail to identify the problem as a known bug, the core in manually analyzed to detect known and unknown bugs.
Manual and automatic housekeeping is performed following this manual analysis.
Brief Description of the Drawings Figure 1 illustrates a block diagram of a system for a panic message analyzer.
Figure 1 B is a block diagram illustrating the core dump of Figure 1.
Figure 2 illustrates a panic message analyzer process in a system for a panic message analyzer.
Figure 3 illustrates an auto support process in a system for a panic message analyzer.
Figure 4 illustrates a core dump process in a system for a panic message analyzer.
Detailed Description of the Preferred Embodiment In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures.
Embodiment of the invention can be implemented using general purpose processors or special purpose processors operating under program control, or other circuits, adapted to particular process steps and data structures described herein. Implementation of the process steps and data structures described herein would not require undue experimentation or further investigation.
Lexicography The following terms refer to or relate to aspects of the invention as described below. The descriptions of general meanings of these terms are not intended to be limiting, only illustrative.
= filer- This term refers to a file server. A file server is a computer and storage device dedicated to data storage and retrieval.
= Core dump- A core dump is the printing or the copying to a more permanent medium (such as a hard disk) the contents of random access memory at one moment in time.
Figure 2 illustrates a panic message analyzer process in a system for a panic message analyzer.
Figure 3 illustrates an auto support process in a system for a panic message analyzer.
Figure 4 illustrates a core dump process in a system for a panic message analyzer.
Detailed Description of the Preferred Embodiment In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures.
Embodiment of the invention can be implemented using general purpose processors or special purpose processors operating under program control, or other circuits, adapted to particular process steps and data structures described herein. Implementation of the process steps and data structures described herein would not require undue experimentation or further investigation.
Lexicography The following terms refer to or relate to aspects of the invention as described below. The descriptions of general meanings of these terms are not intended to be limiting, only illustrative.
= filer- This term refers to a file server. A file server is a computer and storage device dedicated to data storage and retrieval.
= Core dump- A core dump is the printing or the copying to a more permanent medium (such as a hard disk) the contents of random access memory at one moment in time.
= Mini core dump - A subset of data from a core dump.
= Back-trace - A list of computer instructions in the reverse order they were executed.
As noted above, these descriptions of general meanings of these terms are not intended to be limiting, only illustrative. Other and further applications of the invention, including extensions of these terms and concepts, would be clear to those of ordinary skill in the art after perusing this application. These other and further applications are part of the scope and spirit of the invention, and would be clear to those of ordinary skill in the art, without further invention or undue experimentation.
System Elements Figure 1 shows a block diagram of a system for a panic message analyzer.
A system 100 includes a client device 110 associated with a customer, a communications link 120, a communications network 130, a server device 140 associated with a manufacturer, a mass storage 150, a housekeeping database 151, a bugs database 152, and a core dump 160.
The client device 110 includes a processor, a main memory, and software for executing instructions (not shown, but understood by one skilled in the art).
Although the client device 110 and server device 140 are shown as separate devices there is no requirement that they be separate devices.
The communications link 120 operates to couple the client device 110 to the communications network 130.
The server device 140 includes a processor, a main memory, software for executing instructions (not shown, but understood by one skilled in the art), and a mass storage 150. Although the client device 110 and server device 140 are shown as separate devices there is no requirement that they be separate devices. Additionally, although the server device 140 and mass storage 150 are shown as combined there is no requirement that they be combined. They could be separate devices.
The mass storage 150 includes the housekeeping database 151 and bugs database 152.
The core dump 160 includes a mini core dump 161, a back-trace 162, and a panic message 163.
Method of Operation - Manual Message Processing Figure 2 illustrates a panic message analyzer process, indicated by general reference character 200. The manual panic message analyzer process 200 initiates at a `start' terminal 201. The panic message analyzer process 200 continues to a `panic message created' procedure 203 which allows the customer's device to create a panic message 163 prior to failure.
A `customer submits panic message' procedure 205 allows the customer to submit the panic message 163 for analysis utilizing the client device 110 to transmit the panic message 163 to the server device 140. In a preferred embodiment, the customer submits the message via interaction and transfer over an Internet connection which is well-known in the art. There is, however, no requirement the panic message 163 be transferred by this method as long as it is delivered to the manufacturer.
An `analyze panic message' procedure 207 allows the panic message 163 to be analyzed by comparing recognized data elements it contains (a panic message includes the address of where a system was last operating, line numbers, text and source code filenames, and other data) against known data elements that correspond to known bugs in the bugs database 152 on the server device 140.
A `known bug?' decision procedure 209 determines whether the panic message identifies a known bug. If the "known bug?' decision procedure 209 determines that the bug is a known bug, the panic message analyzer process 200 continues to a "solution to customer' 'Procedure 213.
An `investigate via auto support' procedure 211 takes note that analysis of the customer-submitted panic message 163 failed to identify the problem with the affected system and that further investigation is required. The panic message analyzer process 200 continues to an "automatic housekeeping" procedure 215.
The `solution to customer' procedure 213 extracts a solution from the database which is associated with the bug identified by the `known bug' decision procedure 209. The solution provided to the customer can be written instructions detailing how to fix and avoid further occurrences, a copy of a software program to fix the problem, or recommendations for the purchase of additional products from the manufacturer that fix the problem.
An `automatic housekeeping' procedure 215 records all relevant information regarding identification/non-identification of the bug, the solution sent to the customer (if any), and statistics relating to these events in the housekeeping database 151. If the panic message analyzer failed to diagnose the problem, the `automatic housekeeping' procedure leaves the case active (i.e. marked as unresolved).
Method of Operation - Auto Support Analysis Figure 3 illustrates an auto support process, indicated by general reference character 300. The auto support process 300 initiates at a `start' terminal 301. The auto support process 300 continues to an `auto support message sent' procedure 303 which allows the client device 110 to automatically send a message to the sever device 140 containing a copy of the panic message 163 and mini core dump 161.
An `auto support message received' procedure 305 allows the server device 140 to receive the panic message 163 and mini core dump 161 from the client device 110.
= Back-trace - A list of computer instructions in the reverse order they were executed.
As noted above, these descriptions of general meanings of these terms are not intended to be limiting, only illustrative. Other and further applications of the invention, including extensions of these terms and concepts, would be clear to those of ordinary skill in the art after perusing this application. These other and further applications are part of the scope and spirit of the invention, and would be clear to those of ordinary skill in the art, without further invention or undue experimentation.
System Elements Figure 1 shows a block diagram of a system for a panic message analyzer.
A system 100 includes a client device 110 associated with a customer, a communications link 120, a communications network 130, a server device 140 associated with a manufacturer, a mass storage 150, a housekeeping database 151, a bugs database 152, and a core dump 160.
The client device 110 includes a processor, a main memory, and software for executing instructions (not shown, but understood by one skilled in the art).
Although the client device 110 and server device 140 are shown as separate devices there is no requirement that they be separate devices.
The communications link 120 operates to couple the client device 110 to the communications network 130.
The server device 140 includes a processor, a main memory, software for executing instructions (not shown, but understood by one skilled in the art), and a mass storage 150. Although the client device 110 and server device 140 are shown as separate devices there is no requirement that they be separate devices. Additionally, although the server device 140 and mass storage 150 are shown as combined there is no requirement that they be combined. They could be separate devices.
The mass storage 150 includes the housekeeping database 151 and bugs database 152.
The core dump 160 includes a mini core dump 161, a back-trace 162, and a panic message 163.
Method of Operation - Manual Message Processing Figure 2 illustrates a panic message analyzer process, indicated by general reference character 200. The manual panic message analyzer process 200 initiates at a `start' terminal 201. The panic message analyzer process 200 continues to a `panic message created' procedure 203 which allows the customer's device to create a panic message 163 prior to failure.
A `customer submits panic message' procedure 205 allows the customer to submit the panic message 163 for analysis utilizing the client device 110 to transmit the panic message 163 to the server device 140. In a preferred embodiment, the customer submits the message via interaction and transfer over an Internet connection which is well-known in the art. There is, however, no requirement the panic message 163 be transferred by this method as long as it is delivered to the manufacturer.
An `analyze panic message' procedure 207 allows the panic message 163 to be analyzed by comparing recognized data elements it contains (a panic message includes the address of where a system was last operating, line numbers, text and source code filenames, and other data) against known data elements that correspond to known bugs in the bugs database 152 on the server device 140.
A `known bug?' decision procedure 209 determines whether the panic message identifies a known bug. If the "known bug?' decision procedure 209 determines that the bug is a known bug, the panic message analyzer process 200 continues to a "solution to customer' 'Procedure 213.
An `investigate via auto support' procedure 211 takes note that analysis of the customer-submitted panic message 163 failed to identify the problem with the affected system and that further investigation is required. The panic message analyzer process 200 continues to an "automatic housekeeping" procedure 215.
The `solution to customer' procedure 213 extracts a solution from the database which is associated with the bug identified by the `known bug' decision procedure 209. The solution provided to the customer can be written instructions detailing how to fix and avoid further occurrences, a copy of a software program to fix the problem, or recommendations for the purchase of additional products from the manufacturer that fix the problem.
An `automatic housekeeping' procedure 215 records all relevant information regarding identification/non-identification of the bug, the solution sent to the customer (if any), and statistics relating to these events in the housekeeping database 151. If the panic message analyzer failed to diagnose the problem, the `automatic housekeeping' procedure leaves the case active (i.e. marked as unresolved).
Method of Operation - Auto Support Analysis Figure 3 illustrates an auto support process, indicated by general reference character 300. The auto support process 300 initiates at a `start' terminal 301. The auto support process 300 continues to an `auto support message sent' procedure 303 which allows the client device 110 to automatically send a message to the sever device 140 containing a copy of the panic message 163 and mini core dump 161.
An `auto support message received' procedure 305 allows the server device 140 to receive the panic message 163 and mini core dump 161 from the client device 110.
An `analyze panic message' procedure 307 allows the panic message 163 to be analyzed by comparing recognized data elements it contains (a panic message includes the address of where a system was last operating, line numbers, text and source code filenames, and other data) against known data elements that correspond to known bugs in the bugs database 152 on the server device 140.
A 'known panic bug?' decision procedure 309 determines whether the panic message identifies a known bug. If the "known bug?' decision procedure 209 determines that the bug is a known bug, the panic message analyzer process 200 continues to a "discard mini core dump" procedure 321.
An `extract back-trace' procedure 311 extracts the back-trace 162 from the mini core dump 161.
An `analyze back-trace' procedure 313 allows the back-trace 162 to be analyzed using an expression algorithm that looks for exact matches on function names and recognized sequences of function names that correspond to known bugs in the bugs database 152 on the server device 140.
A `known back-trace bug?' decision procedure 315 determines whether the back-trace 162 identifies a known bug. If the `known back-trace bug?' decision procedure 315 determines that the bug is a known bug, the auto support process 300 continues to a "discard mini core dump" procedure 321.
A `request core dump' 317 procedure notifies the customer that a core dump 160 of the affected system is required. This notification includes all the instructions necessary to create the core dump 160 and deliver it to the manufacturer. In a preferred embodiment, the notification would be sent electronically to the customer;
however, there is no requirement that notification be accomplished in this manner.
An `automatic housekeeping' procedure 319 records all relevant information regarding identification/non-identification of the bug, the solution sent to the customer (if any), and statistics relating to these events in the housekeeping database 151. If the panic message analyzer failed to diagnose the problem, the `automatic housekeeping' procedure leaves the case active (i.e. marked as unresolved).
Additionally, if the bug was identified by analysis of the back-trace, functionality exists that allows the back-trace analyzer to teach the panic message analyzer about the bug. This allows future instances of the bug to be resolved at an earlier stage.
For example, if the bug first appeared in version one of the software at line 10, the panic message analyzer would not identify it in version two if the bug now appeared at line 20 due to the exact matching methodology used. The back-trace analyzer, however, might identify the bug as it uses a more sophisticated approach, and it would then pass this information to the panic message analyzer. The auto support process 300 terminates through an `end' terminal 325.
A `discard mini core dump' procedure 321 causes the mini core dump 161 to be discarded as it is no longer needed due to identification of the bug.
A `solution sent to customer' procedure 323 causes a solution to be extracted from the bugs database 152 which is associated with the identified bug. The solution provided to the customer varies depending on the bug identified. For example, it can be written instructions detailing how to fix and avoid further occurrences, a copy of a software program to fix the problem, or recommendations for the purchase of additional products from the manufacturer that fix the problem.
The auto support process 300 continues to an `automatic housekeeping' procedure 319.
Method of Operation - Core Dump Analysis Figure 4 illustrates a core dump process, indicated by general reference character 400. The core dump process 400 initiates at a `start' terminal 401.
The core dump process 400 continues to a `core arrives from customer' procedure 403 which allows analysis of the core dump 160 to begin. The core dump 160 is requested by a' request core dump' procedure 317 (illustrated in Figure 3) when prior analysis of the panic message 163 and back-trace 162 have failed. These two analysis techniques, however, are duplicated during the core dump process 400 further providing fail-safe systematic analysis.
An `analyze panic message' procedure 405 allows the panic message 163 to be analyzed by comparing recognized data elements it contains (a panic message includes the address of where a system was last operating, line numbers, text and source code filenames, and other data) against known data elements that correspond to known bugs in the bugs database 152 on the server device 140.
A 'known panic bug?' decision procedure 407 determines whether the panic message identifies a known bug. If the "known bug?' decision procedure 407 determines that the bug is a known bug, the core dump process 400 continues to a "store core dump"
procedure 423.
An `extract back-trace' procedure 409 extracts the back-trace 162 from the core dump 160.
An `analyze back-trace' procedure 411 allows the back-trace 162 to be analyzed using an expression algorithm that looks for exact matches on function names and recognized sequences of function names that correspond to known bugs within the bugs database 152.
A `known back-trace bug?' decision procedure 413 determines whether the back-trace 162 identifies a known bug. If the `known back-trace bug?' decision procedure 413 determines that the bug is a known bug, the core dump process 400 continues to a `store core dump' procedure 423.
A `core script analyzer' procedure 415 automatically analyzes the core dump 160 by searching for data elements in the core dump 160 that correspond to known bugs within the bugs database 152.
A `known core bug?' decision procedure 417 determines whether core script analysis has identified a known bug. If the `known core bug?' decision procedure 417 determines it has identified a known core bug, the core dump process 400 continues to a `store core dump' procedure 423.
A `manual core dump analysis' procedure 419 allows the core dump 160 to be analyzed manually by personnel at the manufacturer.
A `manual solution sent to customer' procedure 421 allows personnel at the manufacturer to send a solution to the customer based on the manual analysis of the core dump 160. The core dump process 400 continues to a "automatic housekeeping"
procedure 427.
A `store core dump' procedure 423 allows the mini core dump 161 to be moved to a storage location.
A `solution sent to customer' procedure 425 causes a solution to be extracted from the bugs database 152 which is associated with the identified bug. The solution provided to the customer varies depending on the bug identified. For example, it can be written instructions detailing how to fix and avoid further occurrences, a copy of a software program to fix the problem, or recommendations for the purchase of additional products from the manufacturer that fix the problem.
An `automatic housekeeping' procedure 427 records all relevant information regarding identification/non-identification of the bug, the solution sent to the customer (if any), statistics relating to these events, and any entries necessary to the bugs database 152.
Additionally, if the bug was identified by analysis of the back-trace, functionality exists that allows the back-trace analyzer to teach the panic message analyzer about the bug. This allows future instances of the bug to be resolved at an earlier stage.
Furthermore, if the bug was identified by analysis of the core, functionality exists that allows the core to teach the back-trace analyzer and panic message analyzer about the bug. This allows future instances of the bug to be resolved at an earlier stage.
The core dump process 400 terminates through an `end' terminal 429.
Generality of the Invention The invention has general applicability to various fields of use, not necessarily related to the services described above. For example, these fields of use can include one or more of, or some combination of, the following:
= In addition to general applicability to file servers the invention has broad applicability to networks, network devices, and all types of software. Other and further applications of the invention, in its most general form, will be clear to those skilled in the art after perusal of this application, and are within the scope and spirit of the invention.
Alternate Embodiments Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.
A 'known panic bug?' decision procedure 309 determines whether the panic message identifies a known bug. If the "known bug?' decision procedure 209 determines that the bug is a known bug, the panic message analyzer process 200 continues to a "discard mini core dump" procedure 321.
An `extract back-trace' procedure 311 extracts the back-trace 162 from the mini core dump 161.
An `analyze back-trace' procedure 313 allows the back-trace 162 to be analyzed using an expression algorithm that looks for exact matches on function names and recognized sequences of function names that correspond to known bugs in the bugs database 152 on the server device 140.
A `known back-trace bug?' decision procedure 315 determines whether the back-trace 162 identifies a known bug. If the `known back-trace bug?' decision procedure 315 determines that the bug is a known bug, the auto support process 300 continues to a "discard mini core dump" procedure 321.
A `request core dump' 317 procedure notifies the customer that a core dump 160 of the affected system is required. This notification includes all the instructions necessary to create the core dump 160 and deliver it to the manufacturer. In a preferred embodiment, the notification would be sent electronically to the customer;
however, there is no requirement that notification be accomplished in this manner.
An `automatic housekeeping' procedure 319 records all relevant information regarding identification/non-identification of the bug, the solution sent to the customer (if any), and statistics relating to these events in the housekeeping database 151. If the panic message analyzer failed to diagnose the problem, the `automatic housekeeping' procedure leaves the case active (i.e. marked as unresolved).
Additionally, if the bug was identified by analysis of the back-trace, functionality exists that allows the back-trace analyzer to teach the panic message analyzer about the bug. This allows future instances of the bug to be resolved at an earlier stage.
For example, if the bug first appeared in version one of the software at line 10, the panic message analyzer would not identify it in version two if the bug now appeared at line 20 due to the exact matching methodology used. The back-trace analyzer, however, might identify the bug as it uses a more sophisticated approach, and it would then pass this information to the panic message analyzer. The auto support process 300 terminates through an `end' terminal 325.
A `discard mini core dump' procedure 321 causes the mini core dump 161 to be discarded as it is no longer needed due to identification of the bug.
A `solution sent to customer' procedure 323 causes a solution to be extracted from the bugs database 152 which is associated with the identified bug. The solution provided to the customer varies depending on the bug identified. For example, it can be written instructions detailing how to fix and avoid further occurrences, a copy of a software program to fix the problem, or recommendations for the purchase of additional products from the manufacturer that fix the problem.
The auto support process 300 continues to an `automatic housekeeping' procedure 319.
Method of Operation - Core Dump Analysis Figure 4 illustrates a core dump process, indicated by general reference character 400. The core dump process 400 initiates at a `start' terminal 401.
The core dump process 400 continues to a `core arrives from customer' procedure 403 which allows analysis of the core dump 160 to begin. The core dump 160 is requested by a' request core dump' procedure 317 (illustrated in Figure 3) when prior analysis of the panic message 163 and back-trace 162 have failed. These two analysis techniques, however, are duplicated during the core dump process 400 further providing fail-safe systematic analysis.
An `analyze panic message' procedure 405 allows the panic message 163 to be analyzed by comparing recognized data elements it contains (a panic message includes the address of where a system was last operating, line numbers, text and source code filenames, and other data) against known data elements that correspond to known bugs in the bugs database 152 on the server device 140.
A 'known panic bug?' decision procedure 407 determines whether the panic message identifies a known bug. If the "known bug?' decision procedure 407 determines that the bug is a known bug, the core dump process 400 continues to a "store core dump"
procedure 423.
An `extract back-trace' procedure 409 extracts the back-trace 162 from the core dump 160.
An `analyze back-trace' procedure 411 allows the back-trace 162 to be analyzed using an expression algorithm that looks for exact matches on function names and recognized sequences of function names that correspond to known bugs within the bugs database 152.
A `known back-trace bug?' decision procedure 413 determines whether the back-trace 162 identifies a known bug. If the `known back-trace bug?' decision procedure 413 determines that the bug is a known bug, the core dump process 400 continues to a `store core dump' procedure 423.
A `core script analyzer' procedure 415 automatically analyzes the core dump 160 by searching for data elements in the core dump 160 that correspond to known bugs within the bugs database 152.
A `known core bug?' decision procedure 417 determines whether core script analysis has identified a known bug. If the `known core bug?' decision procedure 417 determines it has identified a known core bug, the core dump process 400 continues to a `store core dump' procedure 423.
A `manual core dump analysis' procedure 419 allows the core dump 160 to be analyzed manually by personnel at the manufacturer.
A `manual solution sent to customer' procedure 421 allows personnel at the manufacturer to send a solution to the customer based on the manual analysis of the core dump 160. The core dump process 400 continues to a "automatic housekeeping"
procedure 427.
A `store core dump' procedure 423 allows the mini core dump 161 to be moved to a storage location.
A `solution sent to customer' procedure 425 causes a solution to be extracted from the bugs database 152 which is associated with the identified bug. The solution provided to the customer varies depending on the bug identified. For example, it can be written instructions detailing how to fix and avoid further occurrences, a copy of a software program to fix the problem, or recommendations for the purchase of additional products from the manufacturer that fix the problem.
An `automatic housekeeping' procedure 427 records all relevant information regarding identification/non-identification of the bug, the solution sent to the customer (if any), statistics relating to these events, and any entries necessary to the bugs database 152.
Additionally, if the bug was identified by analysis of the back-trace, functionality exists that allows the back-trace analyzer to teach the panic message analyzer about the bug. This allows future instances of the bug to be resolved at an earlier stage.
Furthermore, if the bug was identified by analysis of the core, functionality exists that allows the core to teach the back-trace analyzer and panic message analyzer about the bug. This allows future instances of the bug to be resolved at an earlier stage.
The core dump process 400 terminates through an `end' terminal 429.
Generality of the Invention The invention has general applicability to various fields of use, not necessarily related to the services described above. For example, these fields of use can include one or more of, or some combination of, the following:
= In addition to general applicability to file servers the invention has broad applicability to networks, network devices, and all types of software. Other and further applications of the invention, in its most general form, will be clear to those skilled in the art after perusal of this application, and are within the scope and spirit of the invention.
Alternate Embodiments Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.
Claims (26)
1. A method comprising:
receiving a panic message including information regarding a failure event of a storage server and a mini core dump of the storage server, the mini core dump representing less than all of a complete core dump of the storage server, wherein the mini core dump contains a back trace of a sequence of executed program instructions and additional information including contents of a random access memory of the storage server;
applying a set of rules to the panic message and information extracted from the mini core dump to attempt to identify a bug in the storage server;
determining that applying the set of rules to the panic message and the information extracted from the mini core dump has failed to identify the bug;
in response to determining that applying the set of rules to the panic message and the information extracted from the mini core dump has failed to identify the bug, obtaining and analyzing a complete core dump of the storage server to identify the bug; and generating an action in response to identifying the bug.
receiving a panic message including information regarding a failure event of a storage server and a mini core dump of the storage server, the mini core dump representing less than all of a complete core dump of the storage server, wherein the mini core dump contains a back trace of a sequence of executed program instructions and additional information including contents of a random access memory of the storage server;
applying a set of rules to the panic message and information extracted from the mini core dump to attempt to identify a bug in the storage server;
determining that applying the set of rules to the panic message and the information extracted from the mini core dump has failed to identify the bug;
in response to determining that applying the set of rules to the panic message and the information extracted from the mini core dump has failed to identify the bug, obtaining and analyzing a complete core dump of the storage server to identify the bug; and generating an action in response to identifying the bug.
2. The method of claim 1, wherein the panic message includes an address value and source code.
3. The method of claim 2, wherein the address value in the panic message is an address of where the storage server was last operating.
4. The method of claim 2, wherein the panic message is responsive to an operation taken by a user of the storage server.
5. The method of claim 4, wherein the operation is electronic transfer of the panic message from the user to a manufacturer of the storage server via a communications network.
6. The method of claim 5, wherein the panic message includes a product release version as entered by the user.
7. The method of claim 1, wherein applying the set of rules comprises comparing the panic message against a first database of known bugs.
8. The method of claim 7, wherein applying the set of rules further comprises identifying the panic message as matching a known bug in the first database.
9. The method of claim 8, wherein the known bug is linked to solutions associated with a version.
10. The method of claim 9, wherein a solution is extracted from the solutions by matching a version entered by the user to the version associated with the known bug.
11. The method of claim 1, wherein the action is delivery of a solution to a user of the storage server.
12. The method of claim 1, wherein the action comprises recording statistics to a second database.
13. The method of claim 12, wherein the statistics comprise information related to the message.
14. The method of claim 1, wherein applying the set of rules comprises analyzing the back trace.
15. A server system comprising:
a processor, a bugs database containing information about known bugs; and a memory storing instructions which, when executed by the processor, cause the server system to perform a process that comprises:
receiving a panic message including information regarding a failure event in a client system and a mini core dump of the client system, the mini core dump representing less than all of a complete core dump of the client system, wherein the mini core dump contains a back trace of a sequence of executed program instructions and additional information including contents of a random access memory of the storage server;
applying the panic message and information extracted from the mini core dump to the bugs database to attempt to identify a bug in the client system;
determining that applying the panic message and the information to the bugs database has failed to identify the bug;
in response to determining that applying the panic message and the information extracted from the mini core dump to the bugs database has failed to identify the bug, requesting and analyzing a complete core dump of the client system to identify the bug; and generating an action in response to identifying the bug.
a processor, a bugs database containing information about known bugs; and a memory storing instructions which, when executed by the processor, cause the server system to perform a process that comprises:
receiving a panic message including information regarding a failure event in a client system and a mini core dump of the client system, the mini core dump representing less than all of a complete core dump of the client system, wherein the mini core dump contains a back trace of a sequence of executed program instructions and additional information including contents of a random access memory of the storage server;
applying the panic message and information extracted from the mini core dump to the bugs database to attempt to identify a bug in the client system;
determining that applying the panic message and the information to the bugs database has failed to identify the bug;
in response to determining that applying the panic message and the information extracted from the mini core dump to the bugs database has failed to identify the bug, requesting and analyzing a complete core dump of the client system to identify the bug; and generating an action in response to identifying the bug.
16. The server system of claim 15, wherein the process comprises analyzing the back trace.
17. The server system of claim 15, wherein the panic message includes an address value and source code.
18. The server system of claim 15, wherein the panic message is responsive to an operation taken by a user of the client system.
19. The server system of claim 18, wherein the operation is electronic transfer of the panic message from the user to a manufacturer via a communications network.
20. The server system of claim 19, wherein the panic message includes a product release version as entered by the user.
21. The server system of claim 20, wherein applying the panic message and the mini core dump to the bugs database comprises identifying the panic message as matching a known bug in the first database.
22. The server system of claim 21, wherein the known bug is linked to solutions associated with a version.
23. The server system of claim 22, wherein a solution is extracted from the solutions by matching a version entered by a user to the version associated with the known bug.
24. The server system of claim 15, wherein the action is delivery of a solution to a user.
25. The server system of claim 15, wherein the action comprises recording statistics to a second database.
26. The server system of claim 25, wherein the statistics comprise information related to the message.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US65820800A | 2000-09-08 | 2000-09-08 | |
| US09/658,208 | 2000-09-08 | ||
| PCT/US2001/029049 WO2002021281A2 (en) | 2000-09-08 | 2001-09-10 | Panic message analyzer |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2420008A1 CA2420008A1 (en) | 2002-03-14 |
| CA2420008C true CA2420008C (en) | 2012-04-03 |
Family
ID=24640348
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2420008A Expired - Fee Related CA2420008C (en) | 2000-09-08 | 2001-09-10 | Panic message analyzer |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1381952A2 (en) |
| JP (1) | JP4979176B2 (en) |
| CA (1) | CA2420008C (en) |
| WO (1) | WO2002021281A2 (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6138126A (en) | 1995-05-31 | 2000-10-24 | Network Appliance, Inc. | Method for allocating files in a file system integrated with a raid disk sub-system |
| US7343529B1 (en) | 2004-04-30 | 2008-03-11 | Network Appliance, Inc. | Automatic error and corrective action reporting system for a network storage appliance |
| US8694997B2 (en) | 2007-12-12 | 2014-04-08 | University Of Washington | Deterministic serialization in a transactional memory system based on thread creation order |
| JP5624480B2 (en) | 2008-03-11 | 2014-11-12 | ユニバーシティ・オブ・ワシントン | Efficient deterministic multiprocessing (DETERMINISTICMULTIPROCESSING) |
| US8453120B2 (en) | 2010-05-11 | 2013-05-28 | F5 Networks, Inc. | Enhanced reliability using deterministic multiprocessing-based synchronized replication |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0291735A (en) * | 1988-09-28 | 1990-03-30 | Tohoku Nippon Denki Software Kk | Maintenance managing system for remote fault |
| US5293612A (en) * | 1989-05-11 | 1994-03-08 | Tandem Computers Incorporated | Selective dump method and apparatus |
| US5111384A (en) * | 1990-02-16 | 1992-05-05 | Bull Hn Information Systems Inc. | System for performing dump analysis |
| JPH04335449A (en) * | 1991-05-13 | 1992-11-24 | Nec Corp | Terminal fault information collecting system |
| SE470031B (en) * | 1991-06-20 | 1993-10-25 | Icl Systems Ab | System and method for monitoring and changing the operation of a computer system |
| JPH05334135A (en) * | 1992-05-28 | 1993-12-17 | Nec Corp | Error information display system for abnormal end of program |
| EP0586767A1 (en) * | 1992-09-11 | 1994-03-16 | International Business Machines Corporation | Selective data capture for software exception conditions |
| US5761407A (en) * | 1993-03-15 | 1998-06-02 | International Business Machines Corporation | Message based exception handler |
| JP2701807B2 (en) * | 1995-09-13 | 1998-01-21 | 日本電気株式会社 | Failure notification device |
| JPH10228395A (en) * | 1997-02-17 | 1998-08-25 | Sekisui Chem Co Ltd | Abnormality diagnostic device for controller |
| US6073255A (en) * | 1997-05-13 | 2000-06-06 | Micron Electronics, Inc. | Method of reading system log |
| JPH1124961A (en) * | 1997-07-08 | 1999-01-29 | Nippon Denki Joho Service Kk | Computer maintenance system |
| JPH1139259A (en) * | 1997-07-15 | 1999-02-12 | Casio Comput Co Ltd | Information processor and recording medium recorded with program |
| JP2000181734A (en) * | 1998-12-16 | 2000-06-30 | Fujitsu Ltd | Restoration method/system for program refernece area, program travel side device, program fault managing device and recording medium which computer can read |
| JP3525410B2 (en) * | 1998-12-16 | 2004-05-10 | 富士通株式会社 | Disaster recovery method and computer readable program recording medium for the same |
-
2001
- 2001-09-10 CA CA2420008A patent/CA2420008C/en not_active Expired - Fee Related
- 2001-09-10 JP JP2002524828A patent/JP4979176B2/en not_active Expired - Fee Related
- 2001-09-10 EP EP01973104A patent/EP1381952A2/en not_active Ceased
- 2001-09-10 WO PCT/US2001/029049 patent/WO2002021281A2/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| JP4979176B2 (en) | 2012-07-18 |
| CA2420008A1 (en) | 2002-03-14 |
| JP2004524596A (en) | 2004-08-12 |
| WO2002021281A3 (en) | 2003-11-06 |
| WO2002021281A2 (en) | 2002-03-14 |
| EP1381952A2 (en) | 2004-01-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7475387B2 (en) | Problem determination using system run-time behavior analysis | |
| US6859893B2 (en) | Service guru system and method for automated proactive and reactive computer system analysis | |
| US7328376B2 (en) | Error reporting to diagnostic engines based on their diagnostic capabilities | |
| US7007200B2 (en) | Error analysis fed from a knowledge base | |
| US7984007B2 (en) | Proactive problem resolution system, method of proactive problem resolution and program product therefor | |
| US7305465B2 (en) | Collecting appliance problem information over network and providing remote technical support to deliver appliance fix information to an end user | |
| US8250563B2 (en) | Distributed autonomic solutions repository | |
| US7984334B2 (en) | Call-stack pattern matching for problem resolution within software | |
| US7483970B2 (en) | Method and apparatus for managing components in an IT system | |
| US8140565B2 (en) | Autonomic information management system (IMS) mainframe database pointer error diagnostic data extraction | |
| US7644393B2 (en) | System and method for storing and reporting information associated with asserts | |
| US20050081118A1 (en) | System and method of generating trouble tickets to document computer failures | |
| US20060288183A1 (en) | Apparatus and method for information recovery quality assessment in a computer system | |
| US20040024726A1 (en) | First failure data capture | |
| JPH0644242B2 (en) | How to solve problems in computer systems | |
| JPH0325629A (en) | Method and system for detecting error in program | |
| US6957366B1 (en) | System and method for an interactive web-based data catalog for tracking software bugs | |
| US20080098365A1 (en) | Performance analyzer | |
| CN112650688B (en) | Automated regression testing method, associated device and computer program product | |
| US8327189B1 (en) | Diagnosing an incident on a computer system using a diagnostics analyzer database | |
| CN111444101A (en) | Method and device for automatically creating product test defects | |
| US20030103310A1 (en) | Apparatus and method for network-based testing of cluster user interface | |
| CA2420008C (en) | Panic message analyzer | |
| JP2003345628A (en) | Method for collecting fault research material, and implementation system therefor and processing program therefor | |
| CN110362464B (en) | Software analysis method and equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20160912 |