Self-optimizing analysis system for core dumps

Abstract

A method for facilitating root cause analysis of software crashes through core dump analysis is disclosed. The method includes receiving a core dump file associated with a software program, identifying unique source code lines in the core dump file for each thread running at the time of the crash, and determining the unique source code lines as salient source code lines according to an abstraction level value indicating the number of occurrences of the salient source code lines in different threads. The method further includes determining an abstraction ratio as a function of the number of salient source code lines and the number of unique source code lines, evaluating whether a predefined abstraction level value needs to be adjusted by determining the unique source code lines as salient source code lines and determining the abstraction ratio, and outputting the evaluated values ​​of the salient source code lines and the abstraction ratio.

Description

[Technical Field]

[0001] The present invention relates generally to methods for facilitating root cause analysis, and more particularly to a computer-implemented method for facilitating root cause analysis of software crashes through core dump analysis. The present invention further relates to a core dump analysis system and a computer program product for facilitating root cause analysis of software crashes through core dump analysis. [Background technology]

[0002] The speed of software development has become a key success factor for software and consulting companies, as well as for enterprises. However, the source code base of today's enterprise software products tends to be large and complex, driven only in part by event-based programming techniques and containerization. This creates challenges for developers of all types, regardless of seniority, when maintaining this software. However, it has become essential to debug defective program code quickly and elegantly, not only during the maintenance phase but also during development.

[0003] Several tools exist to address these volume issues, some of which are described in the topic "Code Spelunking: Exploring Cavernous Code Bases" (see, for example, https: / / queue.acm.\org / detail.cfm?id=945136) or the topic "Code Spelunking Redux" (see, for example, https: / / queue.acm.\org / detail.cfm?id=1483108).

[0004] Beyond the sheer volume of source code, the nature of enterprise software itself presents another dimension of complexity. Enterprise software allows users to perform the same types of tasks simultaneously at high speed, but each task may be competing for the same types of resources. Therefore, today's enterprise software operates in a multitasking and multithreaded manner. For example, a relational database management system (RDBMS) can handle a large number of concurrent transactions that may access the same data using multiple parallel streams.

[0005] In the event of an error that is not handled properly, the software itself may write out diagnostic information for each active execution unit, i.e., for all processes and their associated threads, leveraging system resources to dump diagnostic information. Examples of this type of error are deadlocks, infinite loops, accessing protected memory, or accessing memory that no longer exists. The diagnostic data may represent a snapshot of the process state at the time of the failure. This may include register values, allocated memory, the state and call stack of each thread, etc.

[0006] In the context of Unix-like operating systems, these snapshots are called core dumps or core dump files.Although enterprise software traces status and diagnostic information as it runs to available tracing facilities, software developers often need to analyze the diagnostic data of all contributing processes and / or the core dumps of all involved processes because (i) no suitable trace is available for the current problem, i.e., due to insufficient tracing information in the source code, (ii) the currently active tracing level is too low, causing the trace files to miss important information, or (iii) the system workload at the time the problem occurred caused the tracing information of interest to already be overwritten due to round-robin use of trace files with more recent trace information.

[0007] Therefore, core dumps themselves are not human-readable, and software developers may need the skills to preprocess them. However, even if this skill is not lacking, analyzing core dumps is not an easy task because (i) you do not know which core dumps are relevant to discover the root cause of the problem, or (ii) you do not know what to look for in a formatted core dump to discover the root cause of the problem and resolve it.

[0008] One class of failures that are always difficult to analyze are hang situations such as deadlocks and infinite loops.

[0009] There are already publications addressing similar issues, such as document CN10635646A, which discloses a method for analyzing dump files, including: first, acquiring the dump file and other related collapse information files generated when software collapses; sending the dump file and related collapse information files to storage; classifying, compressing, and storing the collapse information files through the storage end according to the software module; and automatically opening and logging in to the web page where the dump was downloaded. The disclosed method also discloses a reminder to check the analysis result log once the analysis results are obtained, and marking and distinguishing the confirmed analysis logs to avoid repeated checking.

[0010] Additionally, the paper "Code Spelunking Redux" by George V. Neville-Neil, published in acmqueue and its associated online version published February 15, 2021, at https: / / queue.acm.org / detail.cfm?is=148-3108, discloses that computer system programming is becoming increasingly complex and that this fundamentally works against code spelunkers. The paper explains that computers are becoming more powerful and that programming complexity is increasing in many directions, including lines of code, number of modules, and number of systems and subsystems. It describes various options for finding errors in source code, including graphical representations of dependent software modules.

[0011] However, one drawback of existing root cause analysis systems and methods is that they are highly dependent on specific hardware architectures. Furthermore, one class of faults that are consistently difficult to analyze are so-called "hang situations," such as deadlocks and infinite loops.

[0012] Therefore, there may be a need to overcome the problem of "hang situations" and / or software crashes and to propose solutions for easier and more targeted root cause analysis after a software crash. Summary of the Invention

[0013] According to one aspect of the present invention, a computer-implemented method for facilitating root cause analysis of software crashes through core dump analysis may be provided. The method may include receiving at least one core dump file associated with a software program capable of executing multiple threads; identifying unique source code lines in the at least one core dump file for each thread running at the time of the software crash; and determining each of the unique source code lines as a conspicuous source code line according to a predefined abstraction level value. The abstraction level value may indicate a number of occurrences of the conspicuous source code line in different threads.

[0014] The method may further include determining an abstraction ratio as a function of the number of salient source code lines and the number of unique source code lines, evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining the abstraction ratio, and outputting an evaluation of the values ​​of the salient source code lines and the abstraction ratio.

[0015] According to another aspect of the present invention, there is provided a core dump analysis system for facilitating root cause analysis of software crashes through core dump analysis. The system includes a memory communicatively coupled to a processor, the memory storing program code portions that, when executed by the processor, enable the processor to: receive at least one core dump file associated with a software program executable as multiple threads; identify, for each thread running at the time of the software crash, unique lines of source code in the at least one core dump file; and determine each of the unique lines of source code as a significant line of source code according to a predefined abstraction level value. The abstraction level value may indicate the number of occurrences of the significant line of source code in different threads.

[0016] The program code portion may also enable the processor to perform the steps of determining an abstraction rate as a function of the number of salient source code lines and the number of unique source code lines, evaluating whether a predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining an abstraction rate, and outputting an evaluation of the salient source code lines and the abstraction rate value.

[0017] The proposed computer-implemented method for facilitating root cause analysis of software crashes via core dump analysis may provide multiple advantages, technical effects, contributions, or improvements, or a combination thereof.

[0018] The immediate benefit to analysts / programmers searching for the root cause of system crashes, especially application software program crashes, is that the amount of data they may have to walk through and analyze can be greatly reduced. By identifying salient source code lines with a relatively high probability, the analyst / developer can save a lot of valuable time and effort in performing their task, i.e., "finding the bug" that crashes the system.

[0019] Based on this significantly reduced amount of data and the highlighting of salient source code lines that may appear in two or more of the threads that may be running in parallel depending on the abstraction level, the analyst / developer receives exactly those source code lines that are likely to be the cause of a fault or malfunction in the enterprise software program with a high probability.

[0020] Furthermore, in contrast to available solutions, the concepts proposed herein are independent of the underlying hardware and software architectures. Therefore, there are no reads of specific CPU or memory registers or data storage cells that can be linked to the source code of an enterprise software program only with significant effort. The concepts of the present invention may rely on the assumption that those unique source code lines present in threads executing in parallel at the time of a software crash may have a high probability of being involved in the software crash. Depending on the level of abstraction, the method and related system may consider source code lines that appear in, for example, only one, two, three, or more parallel threads of execution. This fact, i.e., correlation between multiple threads, may be one of the advantageous technical effects. The proliferation of multithreaded enterprise (and other) applications and hardware systems supporting multithreaded execution through multikernel architectures creates a need for effective analysis tools to identify not only deadlock situations but also all other types of undesirable software behavior during execution (e.g., sudden crashes, infinite loops, accesses to protected memory, or memory that no longer exists). The ability of the concepts proposed herein to examine concurrently executing threads can be particularly beneficial to analysts / programmers.

[0021] The determination of the recommended range, specifically the adjustment of the lower threshold range value for the abstraction rate percentage, may be performed in parallel using historical data from previously performed source code analyses. In one embodiment, it may be assumed that the upper threshold for the abstraction rate may be fixed at a predefined value, for example, 90%. This self-optimization of the proposed concept may make it even more useful the more core dump analyses are performed. Therefore, it does not matter whether the final root cause analysis was successful or not, i.e., whether RCH=1 or RCH=0 (see below).

[0022] Another advantage over expert judgment is that automated root cause analysis can be closer to the developer's perspective. The generated output may also suggest areas in the program code that may need to be fixed. Thus, although the output is not register, flag states, and processor cycles, practical actionable advice can be provided to the developer in a human-readable, plain text format.

[0023] Further embodiments of the inventive concept applicable to methods and systems are described below.

[0024] According to an advantageous embodiment of the method, the outputted prominent source code lines may be ordered by their frequency of appearance in the thread executing at the time of the crash. This ordering allows developers and crash analysts to get a direct overview between the thread executing at the time of the crash and the problematic source code lines, which may lead the root cause analysis in a promising direction.

[0025] According to a further advantageous embodiment of the method, the step of identifying unique source code lines may further include selecting a subset of threads that are likely to be sufficient for root cause analysis of a given crash, particularly before determining each unique source code line as a salient source code line. This may include, for example, excluding those threads that have a wait status related to a programmed time-dependent delay or a timed wait. Such threads are characterized by being reawakened after a predetermined time has elapsed. Therefore, these threads may be unlikely to contribute to a salient source code line.

[0026] According to a useful embodiment of the method, a predefined abstraction level may indicate how fine-grained the determination of salient source code lines is. The abstraction level may be managed at three different levels, such as low, medium, or high. Experience has shown that good root cause analysis results can be achieved using this three-category abstraction level. However, other granularity levels of abstraction are also possible (e.g., four, five, six, or even ten levels).

[0027] According to a preferred embodiment, the method may also include a step of determining whether the output, i.e., user-visible, evaluation of the abstraction ratio value is within a predefined range. Having the abstraction ratio value within a specific range of values ​​may significantly increase the likelihood of a successful root cause analysis in a short time. Therefore, if the abstraction ratio value is not within the range, the method may be repeated using a different abstraction level.

[0028] According to a further developed embodiment, the method may also include persistently storing a set of data related to the success or failure of the root cause analysis, i.e., (i) a root cause hit value indicating whether the root cause analysis was successful based on execution of the method, and typically always (ii) an associated abstraction ratio value, or (iii) an associated bucket index corresponding to a bucket size value for the entire range of possible values ​​of the abstraction value, or a combination thereof. To this end, buckets (representing range values) may be constructed for the abstraction ratio values, and specific abstraction ratio values ​​may be grouped into the buckets. As an example, if abstraction ratio values ​​can range from 0% to 100% and 10 buckets can be specified, an abstraction ratio value of 35% may be classified into the fourth bucket. Thus, it is assumed that the first bucket represents the range from 0% to 10%, the second bucket represents the range from 11% to 20%, the third bucket represents the range from 21% to 30%, the fourth bucket represents the range from 31% to 40%, and so on. If a 20-bucket schema is used for the same example, the abstraction rate value of 35% may fall into the seventh bucket, ranging from 31% to 35%.

[0029] According to one acceptable embodiment, the method may also include determining a lower or upper threshold for the abstraction rate, or both. The lower and upper thresholds may thus define a region or range of values ​​for the abstraction rate that represents a high probability of successful root cause analysis. For this determination, the aforementioned bucketing and statistical methods applied to past core dump analyses and successful and unsuccessful root cause analyses, based on, for example, Bayes' theorem, may be used.

[0030] According to a useful embodiment, the method may further include deselecting core dump files from a group containing at least two core dump files that do not match other core dump files in the group. It may be determined that the core dump files are related to different core dump analysis issues (e.g., originate from different applications) and therefore do not share a common source event. Therefore, for the proposed method, only core dump files related to the same type of software program issue may be used as input for the proposed concept.

[0031] According to a further elegant and useful embodiment, the method may also include a step of converting at least one core dump file into a human-readable format. For this purpose, existing tools can be easily used. One example is the GNU debugger gdb.

[0032] According to a further advantageous embodiment, the method may be independent of the hardware architecture on which the software program was executed before the at least one core dump file was created. Thus, especially when compared to the state-of-the-art of core dump analysis, the concepts proposed herein are independent of pre-trained systems, particularly those for a particular software stack.

[0033] According to an advanced embodiment, the method may also include the steps of: assembling all possible combinations of at least one received core dump file into a core dump file; (i) identifying unique source code lines; (ii) determining each of the unique source code lines as salient source code lines; (iii) determining an abstraction ratio; and (iv) evaluating whether the predefined abstraction level value needs to be adjusted for further iterations; and selecting the salient source code lines for output that are associated with the highest abstraction ratio. Thus, the salient source code most likely to help resolve the program problem, i.e., find the root cause of the crashed software program, may be presented to the analyst / developer. If this is not possible, the next best result associated with the next lowest abstraction ratio (AR) may be presented to the analyst / developer, who may then attempt to resolve the current problem until the root cause is identified and fixed.

[0034] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium may be any apparatus that may include means for storing, communicating, propagating, or transmitting a program for use by or in connection with an instruction execution system, instruction execution apparatus, or instruction execution device.

[0035] It should be noted that embodiments of the present invention are described with reference to different subject matters. Specifically, some embodiments are described with reference to method-type claims, while other embodiments are described with reference to apparatus-type claims. However, a person skilled in the art will infer from the above and following description that, unless otherwise specified, in addition to any combination of features belonging to one type of subject matter, any combination between features relating to different subject matters, specifically between features of a method-type claim and a feature of an apparatus-type claim, is also considered to be disclosed within this document.

[0036] The above-defined and further aspects of the present invention will be apparent from and will be elucidated with reference to the example embodiments described hereinafter, to which the present invention is not limited.

[0037] By way of example only, preferred embodiments of the present invention will now be described with reference to the following drawings, in which: [Brief explanation of the drawings]

[0038] [Figure 1] FIG. 1 is a block diagram of one embodiment of a computer-implemented method of the present invention for facilitating root cause analysis of software crashes through core dump analysis. [Figure 2] FIG. 1 is a block diagram of one embodiment integrated into the core dump analysis workflow. [Figure 3] FIG. 1 is a block diagram illustrating one embodiment of the proposed concept in a more detailed and more implementation-like form. [Figure 4] FIG. 10 is a block diagram of an extended embodiment that allows for multiple core dumps. [Figure 5] 1 is a block diagram of one embodiment of a core dump analysis system of the present invention for facilitating root cause analysis of software crashes through core dump analysis; [Figure 6] FIG. 6 illustrates an embodiment of a computing system comprising a system according to FIG. 5. DETAILED DESCRIPTION OF THE INVENTION

[0039] In the context of this description, the following conventions, terms or expressions, or combinations thereof, may be used:

[0040] The term "root cause analysis" (RCA) can refer to a known, systematic process for identifying the core reasons for a problem or event and the techniques for addressing them. RCA is based on the fundamental premise that investigating an error may require finding ways to prevent the problem rather than simply "addressing" it. This may be fully applicable to finding the underlying reasons for a software program crash.

[0041] The term "software crash" can refer to an event in which a computer program, such as an enterprise application, stops working properly and terminates, i.e., ceases to run.

[0042] The term "core dump analysis" may refer to the process of diagnosing information that may be generated after a software crash, for example in the form of a core dump file, which may be a binary file containing information about the address where the software program stopped executing properly or about the system status.

[0043] The term "core dump file" may refer to the aforementioned binary file containing information about system, memory, and other variables at the time of a system or software crash. After conversion using gdb (GNU Debugger), a binary core dump file may be converted into a human-readable core dump format. When referring to source code lines, e.g., specific source code lines or analyzed source code lines in a core dump file, we mean the version converted into a readable format.

[0044] The term "software program" may refer to a computer program written in a computer programming language and that may be converted into a machine-readable form so that it can be executed.

[0045] The term "thread" may refer to or relate to the smallest sequence of program instructions that can be managed independently by a scheduler, which may typically be part of an operating system. To improve performance for multiple users on multiprocessor computer systems, modern enterprise applications are very often executed by multiple distinct threads, but may also be executed by multiple identical threads.

[0046] The term "unique source code line" may refer to a line of a computer program (i.e., source code) that may occur many times within a computer program, but that is listed only once so that the source code line is a unique source code line across all threads and all core dump files.

[0047] The term "salient source code lines" may refer to one or more of the unique source code lines that may appear in multiple different threads that were executing at (or just before) the time of the software crash. Whether a unique source code line can be labeled as a salient source code line may depend on the level of abstraction, i.e., the abstraction level. As a general rule, the higher the abstraction level, the more concurrently executing threads should contain the same unique source code line.

[0048] The term "level of abstraction" may refer to the number of parallel execution threads running at the time of a software crash, where the same unique line of source code exists.

[0049] The term "abstraction rate" may refer to a function using the identified unique source code lines and associated significant source code lines. An example is represented by equation (1) described below. The abstraction rate may be suitable for judging the quality of the analysis results because it may be more difficult for the algorithm to find recommendations (i.e., significant source code lines that cause software crashes) when based on the unique source code lines.

[0050] To find a high rate, the algorithm only needs to return a small number of significant source code lines. Moreover, the formula given below (see formula (1)) compared with purely human root cause analysis of defects in real enterprise software is a very good means for quickly identifying errors. Based on this, a best practice range for the abstraction rate was derived. Furthermore, experiments can also prove that the simplification rate rs (e.g., rs = [1 - (unique source code lines) / (analyzed source code lines)]) is a much worse variable for proving the quality of a root cause analysis support system.

[0051] The term "evaluation value" may refer to an indication of whether the resulting abstraction rate is likely to be within a recommended range from a lower threshold abstraction rate to an upper threshold abstraction rate.

[0052] The term "bucket index" may refer to the index of the bucket to which a particular value may relate. If the measurement range may be divided into, for example, 10 buckets, the bucket index may range from 1 to 10 (or from 0 to 9). Thus, if a percentage value of 58% is determined, it may relate to the 6th bucket, and therefore the bucket index is 6.

[0053] Before proceeding to the description of the figures, the concept of the present invention will be explained more generally in several steps.

[0054] Step 1 - Formatting the core dump files: The set of available core dump files is automatically pre-processed to make them human-readable; the set of available core dump files is converted from binary format to text format.

[0055] Step 2—Select a minimal set of relevant core dump files: The set of formatted core dump files may be analyzed to determine a high-confidence subset that is sufficient to further root cause analysis of the current problem. The result of this step may be a list of core dump subsets ordered by confidence. The top of this list may be the first core dump subset, i.e., the most confident subset.

[0056] Step 3—Analyze core dump and generate assessment report: The top of the ordered list of core dump subsets determined in step 2 may be analyzed. This may result in a first assessment of (i) source code lines and (ii) threads that are both likely to contribute to the problem.

[0057] Compared to the initial diagnostic data, the assessment results can ultimately significantly reduce the amount of information an analyst / software developer must review to identify the root cause.

[0058] Step 4—Developer Feedback: If the software developer is able to thoroughly analyze the problem at hand using the set of core dump files provided in Step 3, the procedure may end here. Otherwise, the core dump subset may be moved up by one, and the procedure is repeated at Step 3. In either case, the feedback results may be stored, and the core dump subset and confidence value in a persistent data store may be fed back to Step 2 to improve subset selection.

[0059] Next, we will look at four steps and then the fifth step in more detail and with more examples based on the four-step method.

[0060] Step 1:

[0061] On Unix-like operating systems, core dumps can be processed by the gnu debugger (gdb) to convert the binary dump into a human-readable file. For example, the following command can generate human-readable output containing information about all threads, including their current call stacks, for a particular executable: gdb executable --core core.file --batch --quiet \ -ex "thread apply all bt full" -ex "quit" > core.file.resolved

[0062] Step 2:

[0063] The method may iterate over all elements of the core dump power set using C as the current subset, ignoring the empty set, thus excluding all threads that can be ignored, e.g., threads that perform timed waits because they wait until a timer wakes them up.

[0064] For the remaining threads, the N abstraction rates AR of the current subset C are determined. Using the case of N=3, the following categories are determined: - Cat_1: All source code lines that occur in at least one running thread in all core dumps. This represents the set of salient source code lines SLCat_1. - Cat_2: All source code lines that occur in at least two running threads in all core dumps. This represents the set of salient source code lines SLCat_2. - Cat_3: All source code lines that occur in at least three running threads in all core dumps. This represents the set of salient source code lines SLCat_3.

[0065] The abstraction rate may then be calculated as follows: -AR_1=1-SLCat_1 / slu -AR_2=1-SLCat_2 / slu -AR_3=1-SLCat_3 / slu where slu = number of unique source code lines.

[0066] For a subset C, SLCat n For example, 45% (AR low Lower limit) to, for example, 90% (AR up the highest AR within the range of n and may be stored in a list L. Therefore, L is a list of (C, SLCat n , A.R. n )

[0067] Step 3:

[0068] Next, add the set SLCat to the beginning of the list L created in step 2. n may be displayed. n Based on this, a thread-based view of the problem may be presented. For example, the number of suspicious source code lines or statement text may be displayed per thread per core dump. Root cause analysis may then proceed using the provided information.

[0069] Step 4:

[0070] Finally, the root cause hit RCH (Boolean, problem resolved / unresolved) and the AR used are stored in the persistent data store. The variables used by the persistent data store are: RCH = Root Cause Hit, Boolean AR = Abstraction rate (percentage) AR10B = Abstraction Rate Bucket, bucket ranges from 0 to 9 with 10% granularity AR5B = Abstraction Rate Bucket, bucket ranges from 0 to 19 with 5% granularity

[0071] An example of such a table is shown below:

[0072] [Table 1]

[0073] If the problem is not resolved (RCH=0 and no root cause is identified), step 3 is repeated using the next triplet stored in L.

[0074] Step 5:

[0075] Once sufficient user feedback has been collected, the AR in Step 2 low Use data from successful problem solving to adapt new AR low is determined. This can be done, for example, using Bayes' theorem.

[0076] P(A|B)=[P(A)*P(B|A)] / P(B)

[0077] Here, P(A|B) defines the probability P of event A under condition B.

[0078] Therefore, A=>(RCH==1), i.e., event A represents a root cause hit, and B i =>(AR5B==i), i.e., event B i is AR5B i Represents the use of

[0079] For example, using a 5% abstraction rate bucket granularity, the probability (A|B i) can be calculated as follows: P(A) = [Number of RCHs] / (Number of analyses) P(B i ) = [AR5B used in the analysis i [Number of analyses] / (Number of analyses) P(B i |A)=[AR5B i [Number of successful analyses using] / [Number of successful analyses] P(A|B i )=P(A)*P(B i |A) / P(B i ) Therefore, AR low In step 2, MAX((A|B i )) is used.

[0080] The figures are described in detail below. All descriptions in the figures are schematic. First, a block diagram of one embodiment of a computer-implemented method of the present invention for facilitating root cause analysis of software crashes through core dump analysis is provided. Thereafter, further embodiments are described, as well as an embodiment of a core dump analysis system for facilitating root cause analysis of software crashes through core dump analysis.

[0081] FIG. 1 shows a block diagram of a preferred embodiment of a computer-implemented method 100 for facilitating root cause analysis of software crashes through core dump analysis. As can be derived from the above, root cause analysis is primarily concerned with supporting debugging, i.e., discovering errors in software programs, particularly after a crash. The method includes step 102 of receiving at least one core dump file associated with a software program executable as multiple threads. It is understood that typically, two or more core dump files, usually originating from the same type of application, are available; otherwise, anomalous results can be expected.

[0082] The method 100 also includes step 104 of identifying, for each thread running at the time of the software crash, unique source code lines in at least one core dump file, and step 106 of determining each of the unique source code lines as a salient source code line according to a predefined abstraction level value. The abstraction level value may be received, for example, from a user, at the start of the process. Thus, the abstraction level value indicates the number of occurrences of the salient source code line in different threads.

[0083] At this point, the following intermediate results are possible: Number of source code lines analyzed (sla): 481 (i.e., all lines found in all core dumps) Number of unique source code lines (SLU): 76 (i.e., duplicates are removed from SLA) Number of salient source code lines: 17 (i.e., those source code lines in the slu that the algorithm deemed salient)

[0084] Additionally, the method 100 may generate a number of outstanding source code lines and a number of unique source code lines, for example, in the following format: i The method includes determining 108 an abstraction ratio (AR) as a function of For a given thread, AR=1-slc / slu (1) During the ceremony, slc = number of outstanding source code lines, and slu = number of unique source code lines is.

[0085] Furthermore, the method 100 includes a step 110 of evaluating whether a predefined abstraction level value, i.e., an input parameter, needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining an abstraction rate, which may be based, for example, on a received root cause hit (RCH) value, i.e., whether the root cause of the software crash was found by a human analyst or because the AR value was too poor.

[0086] In a further step, the method 100 includes outputting 112 the salient source code lines and an estimate of the abstraction ratio value, specifically in the form of a percentage value.

[0087] As a further option of the described method 100, AR values ​​based on the collected data (e.g., RCH values, AR values, bucket index values, etc.) can be calculated. low It is also possible to actively evaluate whether an adaptation should be performed. Thus, in this case, the evaluation is based on whether an AR can be within best practice or whether Bayes' theorem predicts that an AR will be performed. low This can be interpreted in terms of whether to first check (i.e., determine) whether enough data is available to determine, perform adaptation, and then perform a value range test as a next step.

[0088] 2 shows a block diagram of one embodiment 200 integrated into a core dump analysis workflow. Block 201 represents an executed software program that may have multiple parallel threads 203, many of which may be identical. For example, in database systems or enterprise applications, which are typically multi-user systems with large user communities performing the same or similar tasks, threads are often identical or run in parallel to improve the overall performance of the application.

[0089] An error in the program code may cause the program code to interrupt or completely stop execution, i.e., crash (206), after a time "t" initiated by the error, resulting in the generation of a core dump file 202. Typically, this is done by a system-level routine.

[0090] At least one core dump file 202 is provided to a version of a proposed core dump analysis system 208. Additionally, an abstraction level 204 (not to be confused with an abstraction rate) may also be input to the core dump analysis system 208. Based on the method 100 described above, the core dump analysis system 208 outputs, specifically, in a user-readable format, salient source code lines 218, an abstraction rate 220 value, and an associated range 222 for the abstraction rate 220. This information, specifically, the salient source code lines, may be used by a source code analyst / programmer to perform their own root cause analysis 212. Any data from the executed proposed method, i.e., the salient source code lines 218, the abstraction level 204 used, the determined abstraction rate 220, and the range 222, along with whether or not it was successful, may then be persistently stored in data storage 210 in the form of a root cause hit value 214 (RCH).

[0091] Figure 3 is a block diagram illustrating one embodiment 300 of the proposed concept in a more detailed and implementation-like format. After receiving the core dump file 202 and the abstraction level AL 204 (see also Figure 2), the process begins in step 302 by analyzing the core dump file, resulting in multiple unique source code lines 304 per thread. The process then proceeds to step 306, where salient source code lines 308 are found, using this as input for the next step. This is done depending on the abstraction level AL 204, i.e., whether salient source code lines 308 can be found in one, two, three, or more parallel execution threads.

[0092] In the next step, the abstraction rate and range recommendations are determined 310 according to equation (1). For a single received core dump, output 312 is generated in the form of salient source code lines 218, abstraction rate 220, and associated ranges 222.

[0093] It is then determined whether the abstraction rate is within range 314. If not, i.e., "N", the process proceeds to step 316 to change the abstraction level and returns to step 302 to analyze the core dump.

[0094] On the other hand, if the abstraction rate value is determined to be within range (314), the process continues with normal root cause analysis (318).

[0095] FIG. 4 shows a block diagram of an expanded embodiment 400 that takes multiple core dump files into account. The process begins with multiple core dump files 202 and an abstraction level 204. First, a group containing all permutations of the core dump files is determined (402). Then, for each permutation of the core dump files 202, the method according to FIG. 1 is performed without user interaction (404). Based on the resulting AR values, the permutations are sorted (406), and the result with the best AR of the permutation is displayed (or otherwise output) to a user, e.g., an analyst / programmer (408). The user may perform their own root cause analysis and input (receive) a root cause hit ("1") or miss ("0") (410).

[0096] If, at decision 412, the RCH value is equal to 1, i.e., the root cause analysis was successful, the process ends 414. Otherwise, the suboptimal result of the permutation is displayed 416, and the procedure is repeated.

[0097] Finally, Figure 5 illustrates a block diagram of an embodiment of a core dump analysis system 500 of the present invention for facilitating root cause analysis of software crashes through core dump analysis. The system 500 includes a memory 502 communicatively coupled to a processor 504, the memory storing program code portions that, when executed by the processor, enable the processor to: receive, specifically by a receiver unit 506, at least one core dump file associated with a software program executable as multiple threads; identify, specifically by an identification unit 508, unique source code lines in the at least one core dump file for each thread running at the time of the software crash; and determine, specifically by a first determination unit, each of the unique source code lines as a salient source code line according to a predefined abstraction level value. The abstraction level value indicates the number of occurrences of the salient source code line within different threads.

[0098] Further, the program code portions of the source code analysis system 500 enable the processor to perform, in particular by the second determination unit, determining an abstraction ratio as a function of the number of salient source code lines and the number of unique source code lines; in particular by the evaluation module 514, evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining the abstraction ratio; and in particular by the computer I / O system 516, outputting evaluation values ​​of the salient source code lines and the abstraction ratio value.

[0099] It is also noted that all functional units, modules, and functional blocks, i.e., process 504, memory 502, receiver unit 506, identification unit 508, first determination unit 510, second determination unit 512, evaluation module 514, and I / O system 516, may be communicatively coupled to each other for signal or message exchange in a selected 1:1 manner. Alternatively, the functional units, modules, and functional blocks may be linked to a system internal bus system 518, possibly for selective signal or message exchange.

[0100] Embodiments of the present invention may be implemented with virtually any type of computer platform, regardless of whether the platform is suitable for storing and / or executing program code. Figure 6 illustrates, by way of example, a computing system 600 suitable for executing program code associated with the proposed method.

[0101] Computing system 600 is merely one example of a suitable computer system, and whether computer system 600 is capable of implementing and / or performing any of the above-described functionality is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the invention described herein. Computer system 600 has components that operate in numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 600 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices. Computer system / server 600 may be described in the general context of computer system-executable instructions, such as program modules, executed by computer system 600. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 600 may also be practiced in distributed cloud computing environments where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0102] As shown, computer system / server 600 is depicted in the form of a general-purpose computing device. Components of computer system / server 600 may include, but are not limited to, one or more processors or processing units 602, a system memory 604, and a bus 606 that couples various system components, including the system memory 604, to the processor 602. Bus 606 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. Computer system / server 600 typically includes a variety of computer system-readable media. Such media can be any available media that is accessible by computer system / server 600 and includes both volatile and non-volatile media, removable and non-removable media.

[0103] The system memory 604 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 608 and / or cache memory 610. The computer system / server 600 may further include other computer system storage media, removable / non-removable, volatile / non-volatile. By way of example only, a storage system 612 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and an optical disk drive may be provided for reading from and writing to removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, or other optical media. In such cases, each may be connected to the bus 606 by one or more data media interfaces. As further illustrated and described below, memory 604 may include at least one program product having a set of program modules (e.g., at least one of which) configured to implement the functionality of embodiments of the present invention.

[0104] A program / utility having a set of program modules 616 (at least one of which) may be stored in memory 604, by way of example and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. The operating system, one or more application programs, other program modules, and program data, or some combination thereof, may each comprise an implementation of a networking environment. The program modules 616 generally implement the functionality and / or methodology of embodiments of the present invention as described herein.

[0105] Computer system / server 600 may also communicate with one or more external devices 618, such as a keyboard, pointing device, display 620, one or more devices that allow a user to interact with computer system / server 600, or any device that allows computer system / server 600 to communicate with one or more other computing devices (e.g., a network card, modem, etc.), or combinations thereof. Such communication may occur via input / output (I / O) interface 614. Additionally, computer system / server 600 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or combinations thereof, via network adapter 622. As shown, network adapter 622 may communicate with other components of computer system / server 600 via bus 606. It should be understood that other hardware and / or software components, not shown, may be used in conjunction with computer system / server 600. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0106] Additionally, a core dump analysis system 500 for facilitating root cause analysis of software crashes through core dump analysis may be attached to the bus system 606 .

[0107] While the description of various embodiments of the present invention has been presented for illustrative purposes, this description is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond those found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0108] The present invention may be embodied as a system, method, or computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0109] The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system for a propagation medium. Examples of computer-readable media may include semiconductor or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Current examples of optical disks include compact disk read-only memory (CD-ROM), compact disk read / write (CD R / W), DVD, and Blu-ray® disk.

[0110] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves with instructions recorded on them, and any suitable combination of the above. As used herein, computer-readable storage media should not be construed as being ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through fiber optic cable), or electrical signals transmitted over electrical wires.

[0111] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0112] Computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry.

[0113] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0114] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable medium, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions implementing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0115] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to create a computer-implemented process that causes the computer, other programmable apparatus, or other device to perform a series of operational steps, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0116] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or actions or a combination of dedicated hardware and computer instructions.

[0117] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms a, an, and the are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used herein, indicate the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0118] Corresponding structure, materials, acts, and equivalents of all means or steps and functional elements within the scope of the appended claims are intended to include any structure, material, or acts for performing a function as specifically claimed in combination with other claimed elements. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described in order to best explain the principles and practical applications of the invention and to enable others skilled in the art to understand the invention in various embodiments with various modifications as suited to the particular uses contemplated.

[0119] Briefly, the inventive concept can be summarized by the following clauses.

[0120] 1. A computer-implemented method for facilitating root cause analysis of software crashes via core dump analysis, comprising: receiving at least one core dump file associated with a software program capable of executing as multiple threads; - identifying unique source code lines in at least one core dump file for each thread running at the time of the software crash; determining each of the unique source code lines as a salient source code line according to a predefined abstraction level value, the abstraction level value indicating the number of occurrences of the salient source code line in different threads; determining an abstraction ratio value as a function of the number of salient source code lines and the number of unique source code lines; evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining an abstraction rate value; - outputting the evaluation values ​​of prominent source code lines and abstraction ratio values; 11. A computer-implemented method comprising:

[0121] 2. The method of clause 1, wherein the outputted salient source code lines are ordered by their frequency of occurrence within the thread running at the time of the crash.

[0122] 3. Identifying unique source code lines Selecting a subset of threads that is likely to be sufficient for root cause analysis of a given crash 3. The method of clause 1 or 2, further comprising:

[0123] 4. The method of any of clauses 1 to 3, wherein the predefined abstraction level indicates how fine-grained the determination of salient source code lines is.

[0124] 5. - determining whether the estimated value of the abstraction ratio is within a predefined range; 5. The method according to any one of clauses 1 to 4, including

[0125] 6. - a root cause hit value indicating whether the root cause analysis was successful based on the execution of the method; - the associated value of the abstraction rate, or - The total range of possible values ​​for the abstraction rate value depends on the bucket size value, the associated bucket index, or a combination thereof 6. The method of any of clauses 1 to 5, also comprising the step of persistently storing

[0126] 7. determining a lower or upper threshold for the abstraction rate, or both, the lower and upper thresholds defining a range for values ​​of the abstraction rate that represent a high probability of successful root cause analysis; 6. The method according to clause 6,

[0127] 8. - Deselecting core dump files from a group that contains at least two core dump files that do not match other core dump files in the group. 8. The method according to any one of clauses 1 to 7, including

[0128] 9. The step of receiving at least one core dump file; -Convert at least one core dump file into human-readable characters 9. The method according to any one of clauses 1 to 8, including

[0129] 10. A method according to any of clauses 1 to 9, wherein the method is independent of the hardware architecture on which the software program was executed before the at least one core dump file was created.

[0130] 11. constructing a core dump file from a possible combination of the at least one received core dump file; (i) identifying unique source code lines; (ii) determining each of the unique source code lines as a salient source code line; (iii) determining an abstraction ratio; and (iv) evaluating whether the predefined abstraction level value needs to be adjusted for further iterations; - Selecting those prominent source code lines to be output that are associated with the highest abstraction rate; 11. The method of any of clauses 1 to 10, including

[0131] 12. A core dump analysis system for facilitating root cause analysis of software crashes through core dump analysis, the system comprising: a memory communicatively coupled to the processor, the memory, when executed by the processor, receiving at least one core dump file associated with a software program capable of executing as multiple threads; - identifying unique source code lines in at least one core dump file for each thread running at the time of the software crash; determining each of the unique source code lines as a salient source code line according to a predefined abstraction level value, the abstraction level value indicating the number of occurrences of the salient source code line in different threads; determining an abstraction ratio value as a function of the number of salient source code lines and the number of unique source code lines; evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining an abstraction rate value; - outputting the evaluation values ​​of prominent source code lines and abstraction ratio values; A core dump analysis system that stores portions of program code that allow a processor to execute a program.

[0132] 13. The system of clause 12, wherein the outputted salient source code lines are ordered by frequency of occurrence within the thread running at the time of the crash.

[0133] 14. While a program code portion identifies a unique source code line, Selecting a subset of threads that is likely to be sufficient for root cause analysis of a given crash 14. The system of claim 12 or 13, further enabling the processor to execute:

[0134] 15. The system of any of clauses 12 to 14, wherein the predefined abstraction level indicates at what fine-grain level the determination of salient source code lines is made.

[0135] 16. The program code part is - determining whether the estimated value of the abstraction ratio is within a predefined range; 16. The system of any of clauses 12 to 15, further enabling the processor to execute:

[0136] 17. The program code part is - at least one value selected from the group, i.e., - a root cause hit value indicating whether the root cause analysis was successful based on the execution of the method; - the associated abstraction rate value, and - The associated bucket index, which depends on the bucket size value for the full range of possible values ​​of the abstraction rate value 17. The system of any of clauses 12 to 16, further enabling the processor to perform the step of persistently storing the

[0137] 18. The program code part determining a lower threshold and / or an upper threshold for the abstraction rate, the lower and upper thresholds defining a range for the abstraction rate that represents a high probability of successful root cause analysis; 18. The system of claim 17, further enabling the processor to execute:

[0138] 19. The program code part is - Deselecting core dump files from a group that contains at least two core dump files that do not match other core dump files in the group. 19. The system of any of clauses 12 to 18, further enabling the processor to execute:

[0139] 20. A computer program product for facilitating root cause analysis of software crashes through core dump analysis, wherein a hierarchy includes a root node and at least one child node including an associated subtree, the computer program product including a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by one or more computing systems or controllers, and wherein the one or more computing systems: receiving at least one core dump file associated with a software program capable of executing as multiple threads; - identifying unique source code lines in at least one core dump file for each thread running at the time of the software crash; determining each of the unique source code lines as a salient source code line according to a predefined abstraction level value, the abstraction level value indicating the number of occurrences of the salient source code line in different threads; determining an abstraction rate as a function of the number of salient source code lines and the number of unique source code lines; evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as salient source code lines and determining an abstraction rate; - outputting the evaluation values ​​of prominent source code lines and abstraction ratio values; A computer program product that causes the

Claims

1. A method for facilitating root cause analysis of software crashes through core dump analysis by computer information processing, receiving at least one core dump file associated with a software program that executes as multiple threads; - identifying a unique source code line in said at least one core dump file for each thread running at the time of said software crash; - determining each of said unique source code lines as a salient source code line according to a predefined abstraction level value, said abstraction level value indicating the number of occurrences of said salient source code line in different threads; - determining an abstraction ratio value as a function of the number of salient source code lines and the number of unique source code lines; - evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining the unique source code lines as the salient source code lines and determining the value of the abstraction ratio; - outputting an evaluation value of the salient source code lines and the value of the abstraction ratio; A method comprising:

2. 2. The method of claim 1, wherein the outputted salient source code lines are ordered by frequency of occurrence within the thread running at the time of the crash.

3. The step of identifying unique source code lines comprises: Selecting a subset of threads that is likely to be sufficient for root cause analysis of a given crash The method of claim 1 further comprising:

4. The method of claim 1 , wherein the predefined level of abstraction indicates how fine-grained the determination of the salient source code lines is.

5. - determining whether the evaluation of the value of the abstraction ratio is within a predefined range; The method of claim 1 , further comprising:

6. a root cause hit value indicating whether the root cause analysis was successful based on execution of the method; the associated value of said abstraction rate, or an associated bucket index depending on the bucket size value of the entire range of possible values ​​of said value of said abstraction ratio, 10. The method of claim 1, further comprising the step of persistently storing the information or a combination thereof.

7. determining a lower and / or upper threshold for the abstraction rate, the lower and upper thresholds defining a range for the value of the abstraction rate that represents a high probability of successful root cause analysis; The method of claim 6, further comprising:

8. - deselecting a core dump file from a group that contains at least two core dump files that do not match other core dump files of the group; The method of claim 1 , further comprising:

9. The step of receiving the at least one core dump file comprises: - converting said at least one core dump file into human readable characters; The method of claim 1 , further comprising:

10. 2. The method of claim 1, wherein the method is independent of the hardware architecture on which the software program was executed before the at least one core dump file was created.

11. - constructing a possible combination of said received at least one core dump file into a core dump file; - performing the steps of (i) identifying the unique source code lines, (ii) determining each of the unique source code lines as the salient source code lines, (iii) determining the abstraction ratio, and (iv) evaluating whether the predefined abstraction level value needs to be adjusted for the further iterations; - selecting those salient source code lines to output that are associated with the highest abstraction rate; The method of claim 1 , further comprising:

12. 1. A core dump analysis system for facilitating root cause analysis of software crashes through core dump analysis, the system comprising: - a memory communicatively coupled to a processor, said memory, when executed by said processor, receiving at least one core dump file associated with a software program that executes as multiple threads; - identifying a unique source code line in said at least one core dump file for each thread running at the time of said software crash; - determining each of said unique source code lines as a salient source code line according to a predefined abstraction level value, said abstraction level value indicating the number of occurrences of said salient source code line in different threads; - determining an abstraction ratio value as a function of the number of salient source code lines and the number of unique source code lines; - evaluating whether the predefined abstraction level value needs to be adjusted for further iterations of the steps of determining unique source code lines as the salient source code lines and determining the value of the abstraction ratio; - outputting an evaluation value of the salient source code lines and the value of the abstraction ratio; and storing a program code portion that causes the processor to execute the following:

13. A computer program for causing a computer to execute the method described in any one of claims 1 to 11.

14. A computer-readable storage medium having the computer program of claim 13 recorded thereon.

Images