Method and system for identifying errors in code

• US 9,201,760 B2
• Filed: 08/16/2013
• Issued: 12/01/2015
• Est. Priority Date: 05/12/2010
• Status: Active Grant

• Current Assignee: Salesforce.com, Inc.
• Original Assignee: Salesforce.com, Inc.
• Inventors: Zheng, Zuye
• Primary Examiner(s): PATEL, KAMINI B
• Application Number:
  US13/969,246
• Publication Number:
  US 20130339799A1
• Time in Patent Office: 837 Days
• Field of Search: 714/38.11
• US Class Current: 1/1
• CPC Class Codes: G06F 11/3612 by runtime analysis performance monitoring G06F11/3466
• CPC Class Codes: G06F 11/362 Software debugging

Abstract

A method for identifying errors in code is provided. The method may include rebuilding object dependencies from a heap dump, calculating memory usage of each object, identifying top consumers of memory by object class, analyzing how much memory each class consumes with respect to how much other classes consume, building a corpus of data that may be used in a progressive machine learning algorithm, and identifying suspect classes. Additionally, the suspect classes and the memory usage statistics of the suspect classes may then be used as an identifying signature of the associated out of memory error. The identifying signature of the associated out of memory error may then be used to compare with the signatures of other out of memory occurrences for identifying duplicate error occurrences.

Claims

1. A method for identifying errors in software code in a multi-tenant environment comprising:

calculating, by a host system, memory usage statistics of each of a group of objects that contributed to a current heap dump, the host system including a set of one or more processors and a memory system including one or more computer readable media by the set of one or more processors;

identifying, by the host system, top consumers of memory by object of the current heap dump;

determining, by the host system, how much memory a given one of the top consumers consumes with respect to how much memory top consumers other than the given one of the top consumers consume;

computing, by the host system, a suspect score based on the determining; and

determining, by the host system, whether the given one of the top consumers is likely to have caused memory issues based on the suspect score.

2. The method of claim 1, further comprising:

building a corpus of data for identifying suspect classes that are responsible for out of memory errors; and

identifying a signature of an associated out of memory error based on at least the suspect classes and the memory usage statistics.

3. The method of claim 2, where the object classes related to an application are sorted by retained heap size into a list;

where a set of top memory consumers, which are a subset of the object classes on the list, which does not include all of the objects classes on the list, are used in building a corpus of data.

4. The method of claim 1, further comprising:

calculating memory usage statistics, the calculating including at least determining a shallow heap; and

determining retained heap usages by traversing through dependency trees of the heap dump.

5. The method of claim 4, the determining of the shallow heap includes at least determining primitive values and sizes of the pointers to other objects.

6. The method of claim 4, where the shallow and retained heaps are grouped together by class to calculate the shallow and retained heaps of entire classes along with the number of objects created for each class;

and

where each class is analyzed for memory leaks or excessive memory usage.

7. The method of claim 1, where the suspect score is based on a mean and standard deviation of a shallow heap size and a retained heap size, a number representing how many objects are referenced by the current class, and an occurrence index value representing a relative size of the retained heap of the current class of the given one of the top consumers with respect to top consumers other than the given one of the top consumers, the score being computed based on a multiplicity of heap dumps stored.

8. The method of claim 1, further comprising:

comparing a signature of the current heap dump associated with an out of memory error with a series of signatures of other heap dumps associated with other out of memory occurrences; and

determining whether the current heap dump is a duplicate or an earlier occurrence.

9. The method of claim 8, further comprising:

computing, based on the comparing of the signatures, a duplication score that is indicative of a probability that the current heap dump is a duplicate of a prior heap dump;

if no occurrence with a similar signature is found then the out of memory error is not considered a duplicate, the computing of the suspect score is performed;

if a similar occurrence is found, including the current heap dump in a set of duplicates of the current heap dump;

computing averages and standard deviations of sizes of shallow and retained heaps of the top consuming classes; and

computing the suspect score for the set with the new heap dump, by the set of one or more processors.

10. The method claim 1, further comprising:

rebuilding, at the host system, object dependencies from a current heap dump.

11. The method of claim 1, the host system having a plurality of servers on which the objects run.

12. The method of claim 11, the host system being a multitenant relational database, and the plurality of sever run copies of a database server for the multitenant relational database.

13. The method of claim 1, further comprising:

searching, by the host system, prior heap dumps for heap dumps that are similar to the current heap dump.

14. The method of claim 13, further comprising:

if a prior heap dump is found that is similar, grouping, by the host system, the prior heap dump together with the current heap dump in a set of similar heap dumps; and

associating information about the set of heap dumps with the current heap dump.

15. The method of claim 14, the computing of the suspect score for each of the top consumers being based on information about the set of heap dumps.

16. The method of claim 14, the computing of the suspect score for each of the top consumers being performed if a prior similar heap was found for the given one of the top consumers.

17. The method of claim 1, the computing of the suspect score being performed for each of the top consumers and being based on the information about memory usage if no prior similar heap dump was found.

18. A non-transitory machine-readable medium carrying one or more instructions for identifying errors in software code in a system, which when executed cause a method to be carried out, the method comprising:

calculating, by a host system, memory usage statistics of each of a group of objects that contributed to a current heap dump, the host system including a set of one or more processors and a memory system including one or more computer readable media by the set of one or more processors;

identifying, by the host system, top consumers of memory by object of the current heap dump;

determining, by the host system, how much memory a given one of the top consumers consumes with respect to how much memory top consumers other than the given one of the top consumers consume;

computing, by the host system, a suspect score based on the determining; and

determining, by the host system, whether the given one of the top consumers is likely to have caused memory issues based on the suspect score.