Abstract:
Systems and methods for automatic determination of out of memory handling situations are provided. A system and method can include receiving data that includes one or more memory allocations or one or more pool heaps and running a test on the data to capture one or more tracebacks. If the one or more tracebacks are unique, then the one or more unique tracebacks are added to a list. The test is run a second time on the first traceback on the list to determine a result that indicates correct execution or incorrect execution with respect to memory handling. The result is stored in a computer-readable storage medium.

Description:
TECHNICAL FIELD 
     The present disclosure relates generally to computer-implemented systems and methods for handling computer memory, and more specifically for automated determination of out of memory situations. 
     BACKGROUND 
     Memory utilization demands within computer systems have increased dramatically as a result of attempting to satisfy computer resource consumption needs of their users. Memory utilization demands cause problems within the computer systems, such as out of memory situations. For example, out of memory situations can occur in complex computer systems that handle numerous users. When an out of memory situation occurs, a computer system can react in different and often unpredictable ways. In some instances, the computer system may be able to repair itself and continue operations, but in other instances, the out of memory situation can cause the computer system to crash. 
     Instances of memory allocation can be checked by limiting the amount of memory available in a computer system and monitoring how the computer system reacts. However, handling memory allocations in this way often results in only a limited number of instances of memory allocation being checked in the computer system. Accordingly, many instances of memory allocation in the computer system may be unchecked. Still further, the reasons for why the computer system ran out of memory and where the computer system ran out of memory remain uncertain. 
     SUMMARY 
     In accordance with the teachings provided herein, systems and methods for operation upon data processing devices are provided to automatically determine out of memory situations. For example, a system and method can be configured to receive data that includes one or more memory allocations or one or more pool heaps and configured to run a test on the data to capture one or more tracebacks. If the one or more tracebacks are unique, then the one or more unique tracebacks are added to a list. The test is run a second time on the first traceback on the list to determine a result that indicates correct execution or incorrect execution with respect to memory handling. The result is stored in a computer-readable storage medium. The system and method can be further configured to identify a reason for an out of memory situation, wherein the reason is generated by analyzing one or more of the tracebacks when a system fault or a system lockup occurs. As an illustration, the reason for the incorrect execution can indicate that the incorrect execution arose because an application did not properly handle a null pointer. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a block diagram of example system components for automatically determining out of memory situations. 
         FIG. 2  shows a block diagram of an example system for automatically determining out of memory situations. 
         FIG. 3  shows a block diagram of another example system for automatically determining out of memory situations. 
         FIGS. 4A and 4B  together show an example method for automatically determining out of memory situations. 
         FIG. 5  shows an example display of a test for specific tracebacks. 
         FIGS. 6A  ans  6 B together show an example display of an interface application window indicating the specific traceback tested. 
         FIGS. 7A and 7B  together show another example display of the interface application window including an incremental count of iterations being tested. 
         FIGS. 8A and 8B  together show yet another example display of the interface application window including the last iteration tested. 
     
    
    
     Like reference numbers and designations in the various drawings indicate like elements. 
     DETAILED DESCRIPTION 
       FIG. 1  depicts at  100  a system for testing an application  20  for out of memory handling situations. In the system  100 , an automated tester  15  checks allocations of memory  10  by the application  20  in order to determine whether the application  20  handles out of memory situations correctly. If an out of memory situation occurs during the check, the automated tester  15  provides detection of the situation and reason(s) for why the situation occurred. 
     To provide detection and analysis of out of memory situations for the application  20 , the automated tester  15  can be implemented in several phases, such as an instrumentation phase  22 , initialization phase  25 , a capture phase  30 , and a test phase  35 . An instrumentation phase  22  can insert code into application  20 , such that application  20  is configured to capture every allocation and pool create in system  100 . After application  20  is instrumented, the automated tester  15  can begin the initialization phase  25 . During the initialization phase  25 , the automated tester  15  can prime the system and perform any initialization needed (e.g., as required by a particular application being processed). 
     After the initialization phase  25 , the automated tester  15  can signal the application  20  to begin the capture phase  30 . During the capture phase  30 , the application  20  captures one or more lines of code (e.g., a traceback), from each allocation and pool create in the system  100 . A traceback can be one or more lines of code that can provide debugging information for system  100  using execution history data about program problems (e.g., a crash or a lock up). In some implementations, during the capture phase  30 , the application  20  can capture a traceback comprising ten lines of code. In other implementations, during the capture phase  30 , the application  20  can capture more than ten lines of code or can capture less than ten lines of code. 
     Upon completion of the capture phase  30 , the system can compare the captured tracebacks, and the system can save the unique tracebacks (e.g., in memory  10 ). In some implementations, unique tracebacks can be determined automatically by the system as described herein. Still further in some implementations, the number of unique tracebacks can be set as a count. In some implementations, a filter (not shown) can be used to filter out or remove one or more tracebacks from the count (e.g., tracebacks that have already been tested or tracebacks with known crashes). 
     Upon completion of the capture phase  30 , the system initiates the test phase  35  to simulate an out of memory condition. During the test phase  35  the automated tester  15  can re-submit the test a number of times that is equivalent to the count that was set during the capture phase  30 . Additionally, the automated tester  14  can signal the application  20  regarding which instances of the unique tracebacks will be tested. During the test phase  35 , in some implementations, the test can be restarted at least a number of times equivalent to the count. In some implementations the test can be restarted a number of times that is greater than the count. In this latter situation if the traceback is not found, then the system is stopped and then restarted so that the test for that iteration can be tried again. In some implementations, each restart of the test can be a new iteration of the test. 
     During the test phase  35 , the application  20  can compare each captured traceback with a specific unique traceback. In some implementations, when the tracebacks match, a null pointer (e.g., from the memory allocation or pool creation routine), can be returned. Upon receiving a null pointer, the instrumented application  20  can allow the rest of the current iteration of the test execute. In these implementations, while the rest of the iteration of the test is executing, additional tracebacks are not checked. 
     Additionally, while the rest of the iteration of the test is executing, the application  20  can monitor and capture test results. For example, when the iteration of the test causes the application  20  to crash, a traceback of the crash (e.g., the current traceback), can be captured and saved in a file along with the traceback of the last allocation where a null pointer was returned (e.g., the exception traceback). In this example, the application  20  can write remaining untested unique tracebacks (e.g., unique tracebacks in the count which have not been tested), to a file and then the application  20  can terminate (e.g., using a “crash” code). The test phase  35  can include other types of out of memory analysis as described below with respect to example operational scenarios. 
     The test results can be reported and can include information about any crashes and lockups that occurred during the test phase  35 . The test results can be saved to memory  10 , saved to disc (not shown), printed, or otherwise made available for review. Reports can be useful to verify that all instances of memory allocation in the system have been checked. Reports can also provide reasons why an application ran out of memory and where the application ran out of memory. Additionally, reports can facilitate a determination regarding how the system will react to an out of memory situation before the occurrence of an out of memory situation. 
     The system  100  described above can be implemented in numerous configurations. For example, in some implementations, the automated tester  15  can be located on the same computer as the application  20  being tested. This configuration is described below respectively with reference to  FIGS. 2 and 3 . 
       FIG. 2  shows a block diagram of an example system  200  for automatically determining out of memory situations. In some implementations, the automated tester  203  is located on the server(s)  203  and the application  20  (not shown) is also located on the server(s)  203 . Users can interact with the system  200  through a number of ways, such as over one or more networks  202 . One or more data stores  204  can store the data to be analyzed by the system  200  as well as any intermediate or final data generated by the system  200 . Examples of networks  202  include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet. 
       FIG. 3  shows a block diagram of another example system  300  for automatically determining out of memory situations. In system  300 , a user can interact with the system  300  using a stand-alone computer  301  including a memory  10 , an automated tester  15 , and an instrumented application  20 . 
       FIGS. 4A-4B  together provide an example of an operational scenario  400  of an automated tester for automatically determining out of memory situations. Method  400  can begin with the instrumenting  401  of all memory allocation and pool/heap create routines. A first iteration of the test can then be run  402  to capture a traceback from each allocation and pool create in the system. During the first iteration of the test, a determination can be made as to whether the first iteration of the test has been completed  403 . 
     If the first iteration of the test has not been completed, the application  20  can continue to determine if additional memory allocations or pool creates  404  exist which need to be tested. If no additional memory allocations or pool creates  404  exist which need to be tested, then a determination can be made again as to whether the first iteration of the test has been completed  403 . If additional memory allocations (or pool creates)  404  exist which need to be tested, the application  20  can capture a traceback  405  for each remaining memory allocation and pool create  404  needing to be tested. Additionally, the application  20  can determine whether each captured traceback is unique  406 , as described above. If the application  20  does not determine that a captured traceback is unique  406 , the application  20  can continue to determine if additional memory allocations (or pool creates)  404  exist which need to be tested. If the application determines that a captured traceback is unique  406 , the application can add that traceback to a unique traceback list (e.g., the count)  407 , and then application  20  can continue to determine if additional memory allocations (or pool creates)  404  exist which need to be tested. 
     If the first iteration of the test has been completed, the application  20  can determine whether any unique tracebacks exist (e.g., on the list) which need to be tested  408  (e.g., Step A). If a unique traceback on the list needs to be tested  408 , the application  20  can run a next iteration of the test to compare each captured traceback  405  with a unique traceback  406 . If no captured traceback  405  is found to match the unique traceback  406  being tested during the next iteration, the application  20  can save the unique traceback  406  (e.g., on another list  412 ), and the application  20  can be restarted  409 . Once restarted, the application  20  can subsequently proceed to run a next iteration of the test  410  using the first traceback on the list  407  (e.g., Step B). When the next iteration of the test  410  is run using the first traceback on the list, the first trackback can be taken off the list  410  (e.g., thus reducing the count by one). 
     After the next (or now “current”) iteration of the test is run  410 , the application  20  can determine if the current iteration of the test ran to completion  411 . If the current iteration of the test has run to completion, the application  20  can determine whether a captured traceback  405  was found. As noted above, if no captured traceback  405  is found to match the unique traceback  406  being tested during the next iteration, the application  20  can save the unique traceback  406  (e.g., on another list  412 ), and the application  20  can be restarted  409 . Once restarted, the application  20  can subsequently proceed to run a next iteration of the test using the first traceback on the list  410  (e.g., Step B). 
     If the current iteration of the test has not run to completion, the application  20  can determine whether a memory allocation (or pool create) exists for which a traceback was not captured  413 . If no memory allocation (or pool create) exists for which a traceback has not been tested, the application  20  can subsequently determine whether the current iteration of the test has run to completion  411 . 
     If a memory allocation (or pool create) exists for which a traceback has not been captured, the application  20  can proceed to capture that traceback  414  and compare it to the unique traceback  406  being tested. If the application  20  does not determine that a captured traceback  405  matches the unique traceback  406  being tested (the traceback from step B), the application  20  can subsequently determine  415  whether the current iteration of the test has run to completion  411 . If the application  20  does determine  415  that a captured traceback  405  matches the unique traceback  406  being tested, the application  20  can set a “null” allocation  416  with respect to the unique traceback  406 . Additionally, the application  20  can allow the remainder of the current iteration of the test to execute  417  (e.g., without checking any further allocations of unique tracebacks  406  on the list). 
     While the remainder of the current iteration of the test is running, the application  20  can monitor the test to determine whether the current iteration of the test gets an exception  418  (e.g., crashes). If the current iteration of the test does not get an exception  418 , in some implementations, the application  20  can next determine if the current iteration of the test gets hung in an infinite loop  419  (e.g., gets locked up). If the current iteration of the test does not get hung in an infinite loop  419 , in some implementations, the application  20  can next determine if any unique tracebacks  406  are left to be tested  408  (step A). 
     If the current iteration of the test gets an exception  418 , the application  20  can save the unique traceback being tested (i.e., the current traceback being tested) along with a traceback of the exception  420  (step C). In some implementations, the application  20  can next determine if any unique tracebacks  406  are left to be tested  408  (step A). Additionally, if application  20  determines that unique tracebacks  406  are left to be tested  408 , the application  20  can be restarted  409  and subsequently run the next iteration of the test using the first traceback off the list  410 . 
     If the current traceback gets hung in an infinite loop  419 , the application  20  can save the unique traceback (i.e., the current traceback being tested) along with information indicating that the current traceback locked up during the test  421  (step D). In some implementations, the application  20  can next determine if any unique tracebacks  406  are left to be tested  408  (step A). Additionally, if application  20  determines that unique tracebacks  406  are left to be tested  408 , the application  20  can be restarted  409  and subsequently run the next iteration of the test using the first traceback off the list  410 . 
     If the application  20  determines  408  that the first iteration of the test has been completed, the application  20  can next determine  422  whether any unique tracebacks  406  exist (e.g., on list  412 ) for which captured tracebacks  405  were not found. If application  20  determines that a unique traceback  406  exists for which a captured traceback was not found, the application  20  can restart step A  423  using those unique tracebacks. Additionally, the application  20  can run the next iteration of the test  410  using those unique tracebacks  406 . Alternatively, if the application  20  determines that no unique traceback  406  exists for which a captured traceback was not found, the application  20  can proceed to print out a report of all captured problems  424 . 
     It should be understood that similar to the other processing flows described herein, the steps and the order of the steps in the flowchart described herein may be altered, modified, removed and/or augmented and still achieve the desired outcome. A multiprocessing or multitasking environment could allow two or more steps to be executed concurrently. 
       FIG. 5  shows an example display  500  of a test for specific tracebacks. In some implementations, a window  501  (e.g., a DOS window) can be used to implement instructions for executing an application (e.g., a Root Cause Interface Application or “RIA”) and a file  502  (e.g., a configuration file for a null probe). The window can enumerate particular tracebacks to be tested (e.g., unique tracebacks). For example, an indication (e.g., only TKEDSExecute  503 ) can limit which tracebacks will be tested. In this example, only tracebacks that include “TKEDSExecute” will be executed. 
       FIGS. 6A-6B  together show an example display  600  of an interface application or RIA window  601  indicating the specific traceback being tested. In some implementations, the RIA window  601  can correspond to the RootCause Interface Application  502  executed in the DOS window  501 . The RIA window can include one or more buttons (e.g., “stop” button  602 , “kill” button  603 , and “again” button  604 ), which can facilitate user interaction with the application. RIA window  601  includes an indication  605  that a process (e.g., the null probe) has started. Additionally, RIA window  601  includes an indication  606  that a filter (e.g., v920.filt) is being applied, and an indication  607  that only tracebacks containing “TKEDSExecute” will be considered “unique tracebacks.” At  608 , the RIA window  601  includes an indication that a count phase (which is part of the capture phase) will be run (e.g., to determine a number of unique allocations). Once the count phase has finished, the RIA window  601  includes an indication  609  that the filters are checked. 
     In RIA window  601 , an indication  610  displays the results of the count phase. Specifically, 26,876 total allocations were tested, 5,303+156 unique allocations were discovered and 5,303 of those allocations were filtered (e.g., because they did not contain the “TKEDSExecute”). Additionally, RIA window  601  can include one or more indications  611  that an iteration of the test caused the application to terminate (e.g., by producing a crash). In some implementations, when the application terminates, a new version of the application can be started  605 . In these implementations, the application can begin testing unique tracebacks from the point at which the application terminated during a last iteration of the test. 
       FIGS. 7A-7B  together show another example display  700  of the interface application window  601  including an incremental count of iterations being tested. As noted with reference to REFS.  6 A and  6 B above, 26,876 total allocations were tested during the count phase. As shown in  FIGS. 7A-7B , following a first few iterations of the test which caused the application to terminate, subsequent iterations of the test do not cause the application to terminate. Additionally, as shown in RIA window  601 , each subsequent successful iteration of the test can allow the count to increment  701 . In some implementations, the count will continue to increment until the count matches the total number of allocations tested during the count phase (i.e., 26,876).  FIGS. 8A-8B  shows yet another example display  800  of the interface application window  601  including the last iteration tested  801 . 
     While this specification contains many specifics, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of the invention. Certain features that are described in this specification in the context or separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination. 
     Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. 
     Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus. 
     The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device  10 , a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The systems&#39; and methods&#39; data (e.g., associations, mappings, data input, data output, intermediate data results, final data results, etc.), may be stored and implemented in one or more different types of computer-implemented data stores, such as different types of storage devices and programming constructs, such as data structures. It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program. 
     The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them, A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus. 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. 
     The methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem. The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). 
     The computer program instructions may include source code, object code, machine code, or any other stored data that is configured to cause a processing system to perform the methods and operations described herein. Other implementations may also be used, however, such as firmware or even appropriately designed hardware configured to carry out the methods and systems described herein. A computer program (also known as a program, software, software application, script, or code), can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., on or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.