Browse Prior Art Database

Method and System for Automatically Detecting Address Space Memory Leak

IP.com Disclosure Number: IPCOM000245046D
Publication Date: 2016-Feb-06
Document File: 7 page(s) / 221K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method and system is disclosed for automatically detecting address space memory leak.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 7

Method and System for Automatically Detecting Address Space Memory Leak

Performing memory leak detection mandates collection of dumps of address spaces and data spaces, which require

detecting leaks before and after workload. Then the dumps are to be analyzed manually and compare with the before and after storage areas for patterns that may point to evidence of a memory leak. The amount of storage that is allocated to trusted computing base (TCBs), common storage area (CSA), SQA, etc. before running the workload, is required to be analyzed and compared it with the storage that is allocated after running the workload. The significant pattern difference that is observed suggests a memory leak and this manual process might take days due to the large number of storage areas that need to be researched. There needs a method and system that provides a way to automatically detect anomalies to pinpoint potential memory leaks.

Disclosed is a method and system for automatically detecting address space memory leak. The method and system automatically detect anomalies to pinpoint potential memory leaks in given dumps, before and after running a given

workload. The anomalies that are detected can be such as, but not limited to, unallocated memory in the dumps before the workload(s), and running unallocated memory and allocated in the dumps after the workload(s). The anomalies are generated from data contained within value stream mapping data (VSMDATA) report based on identification by TCB, identification by eye catcher, identification by cell pools and identification within common storage managed by VSM.

In accordance with the method and system, for each active TCB in the address space, the VSMDATA report, scans for anomalies for the data that is allocated to each TCB. Subsequently, patterns from the VSMDATA report are identified by analyzing DQEs and FQEs and a report containing the difference in the amount of memory allocated to a given TCB is generated between the duration that is available before and after the dump. Further, a user or an administrator is also allowed to specify one or more desired subpools and/or keys of TCBs to be displayed in this report. The difference in memory allocation size is accordingly reflected in the specification.

In an exemplary scenario, for a given DUMP before workload, with the following data for TCB at address 007FD520:

Data for subpool 229, key 5 follows:

DQE: Addr 7F0F8000 Size 1000


***** Subpool 229, key 5 Total alloc: 1000 ( 0 Below, 1000 Above )

1


Page 02 of 7

Given a DUMP after workload with the following data for TCB at address 007FD520:

Data for subpool 229, key 5 follows:

-- DQE Listing (Virtual 31, Real 64)

DQE: Addr 79DC4000 Size 3000
FQE: Addr 79DC4000 Size 530

DQE: Addr 79DC7000 Size 3000
FQE: Addr 79DC7000 Size 280

DQE: Addr 79DCA000 Size 3000
FQE: Addr 79DCA000 Size 220

DQE: Addr 79DCD000 Size 3000
FQE: Addr 79DCD000 Si...