Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Computer Method for Tracking Debug Objects in Multiple Heaps

IP.com Disclosure Number: IPCOM000123090D
Original Publication Date: 1998-May-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 80K

Publishing Venue

IBM

Related People

Benayon, JW: AUTHOR [+2]

Abstract

Debug heap objects require a list to be maintained with information about the objects for tracking allocated objects and verification of the internal object areas during heap validation.

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

Computer Method for Tracking Debug Objects in Multiple Heaps

   Debug heap objects require a list to be maintained with
information about the objects for tracking allocated objects and
verification of the internal object areas during heap validation.

   To date, our previous implementation stored the
debug information for the object within the object header itself.
Although this was simple, it was not ideal since heap errors could
destroy valuable information that could assist the user in isolating
the problem.  Furthermore, this increased the size of the object
itself and caused alignment problems as the quantity of debug
information stored increased.

   Validation of heap objects within C/C++ runtime libraries
has often been implemented using guard values at the start and end of
each object.  In addition, filename, line and other information
related to the object allocation were also placed in the object
header for simplified retrieval.  The disadvantage of this method is
that this information can easily be overwritten by a bad heap
operation or invalid range specified in a memset call.

   To simplify the operation of walking all the heap objects
for leak analysis and to store more information about the object, a
table structure as follows is a preferable solution:

                            (Image Omitted)

   The table consists of a status that denotes if the entry
is available or used.  The object address is the value returned by
malloc etc. to the caller and filename/line is the location in the
user application where this call was made from.  The call stack is
saved by recording the return addresses where the call was made to
provide additional information in reports on heap
errors and leaks.   This table must be allocated from storage
belonging to a user heap to ensure the table is accessible in all
processes when shared memory heaps are involved.

   Table entry insertion occurs when an object is allocate...