Browse Prior Art Database

Mechanism for diagnosing a double cell pool free problem when modules doing double free are not known.

IP.com Disclosure Number: IPCOM000013835D
Original Publication Date: 2001-May-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 6 page(s) / 46K

Publishing Venue

IBM

Abstract

The code that is developed checks each cell pool get or free request and first determines if the cell is to be monitored or not based on the cell pool ID. If the cell is to be monitored then a GTF trace record will be produced indicating rather the request was for a get or a free. If it is for a free the code will also run the free chain to verify rather the indicated cell is on the free chain or not. The code can easily be modified through the use of slip traps with action=REFBEFOR to change, the cell pool to be monitored and the maximum number of cells to scan on the free chain before the chain is considered to be circular. The code is capable of doing the above monitoring without significant performance degradation on the monitored cell pool and no noticeable impact on the non-monitored cell pools. The actual code, including a discriptive prolog, is shown below: ++USERMOD(JCPCTRP) . ++VER(Z038) FMID(HBB6606) Trap ID: JCPCTRAP OPERATION AND DESCRIPTION: This trap modifies all calls to IGVCPOOL. It is designed with minimal performance impact intended for cellpools other than the one to be monitored. On a cellpool get request the trap will check the cellpool ID and compare it against the cellpool to be monitored. This cellpool ID is a constant value that is stored in the PSA at X'4E4'. Initially it is set to 99 decimal so that no cellpool is to be monitored. If the cell is not the one that we are interested in then the trap simply returns normally. Total additional path length on a get request for a cellpool not being monitored is 5 instructions. For a cellpool free request for a monitored cellpool the additional path length is dependant on the length of the free chain. If this is a cellpool free request that we are monitoring then the trap will run the free chain to see if the element being freed is already on the chain. In the course of running the chain the trap will on the chain. In the course of running the chain the trap will check for circularity as well as a double free. Because it is not possible to run the free chain with serialization this trap depends on the free cells being above the 16M line and the in use cells filling in the first word of the cell with an address below the 16M line. This is true for the JCPC cellpool. On a get request the logic is to check to see if this is the cell pool to be monitored and if it is cut a trace record. If not simply return as normal. Added path length on a non-monitored path is 3 instructions while added path length on a monitored path is 4 instructions. Set-up required: Install this trap with SMP/E ****DO NOT ACCEPT THIS

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

Page 1 of 6

  Mechanism for diagnosing a double cell pool free problem when modules doing double free are not known.

   The code that is developed checks each cell pool get or free request and first determines if the cell is to be monitored or not based on the cell pool ID. If the cell is to be monitored then a GTF trace record will be produced indicating rather the request was for a get or a free. If it is for a free the code will also run the free chain to verify rather the indicated cell is on the free chain or not. The code can easily be modified through the use of slip traps with action=REFBEFOR to change, the cell pool to be monitored and the maximum number of cells to scan on the free chain before the chain is considered to be circular. The code is capable of doing the above monitoring without significant performance degradation on the monitored cell pool and no noticeable impact on the non-monitored cell pools. The actual code, including a discriptive prolog, is shown below:

++USERMOD(JCPCTRP) .

++VER(Z038) FMID(HBB6606) /*
***********************************************************************

* Trap ID: JCPCTRAP *
* *
* OPERATION AND DESCRIPTION: *
* This trap modifies all calls to IGVCPOOL. It is designed with *
* minimal performance impact intended for cellpools other than *
* the one to be monitored. On a cellpool get request the trap *
* will check the cellpool ID and compare it against the cellpool *
* to be monitored. This cellpool ID is a constant value that is *
* stored in the PSA at X'4E4'. Initially it is set to 99 decimal *
* so that no cellpool is to be monitored. If the cell is not the *
* one that we are interested in then the trap simply returns *
* normally. Total additional path length on a get request for *
* a cellpool not being monitored is 5 instructions. For a cellpool *
* free request for a monitored cellpool the additional path length *
* is dependant on the length of the free chain. If this is a *
* cellpool free request that we are monitoring then the trap will *
* run the free chain to see if the element being freed is already *
* on the chain. In the course of running the chain the trap will *
* on the chain. In the course of running the chain the trap will *
* check for circularity as well as a double free. Because it is *
* not possible to run the free chain with serialization this *
* trap depends on the free cells being above the 16M line and the *
* in use cells filling in the first word of the cell with an *
* address below the 16M line. This is true for the JCPC cellpool. *
* On a get request the logic is to check to see if this is the *
* cell pool to be monitored and if it is cut a trace record. If *
* not simply return as normal. Added path length on a non-monitored *
* path is 3 instructions while added path length on a monitored *
* path is 4 instructions. *
* *
* Set-up required: *
* Install this trap with SMP/E ****DO NOT ACCEPT THIS *

1

Page 2 of 6

  * USERMOD****. *
* *
* The following slips are needed to be set in order to acti...