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

Protection against Invalid Pointers

IP.com Disclosure Number: IPCOM000113811D
Original Publication Date: 1994-Oct-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 6 page(s) / 193K

Publishing Venue

IBM

Related People

Blaschke, DE: AUTHOR [+2]

Abstract

Disclosed is a method for using exception handlers to capture access violations, which is optimized for use in a stack-based exception handler environment, maximizing performance by minimizing operating system intervention, normal execution path length, and repetitious code. This method, which allows one handler to be used by all routines in an application, is also re-entrant because the necessary information is preserved on the stack.

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

Protection against Invalid Pointers

      Disclosed is a method for using exception handlers to capture
access violations, which is optimized for use in a stack-based
exception handler environment, maximizing performance by minimizing
operating system intervention, normal execution path length, and
repetitious code.  This method, which allows one handler to be used
by all routines in an application, is also re-entrant because the
necessary information is preserved on the stack.

      The Intel* 80x86 architecture transfers control during program
execution by means of interrupts and exceptions.  Both of these
methods alter the flow of a program to handle external events or to
report error conditions.  Interrupts signal events occurring
externally to the processor, while exceptions signal errors detected
within the processor.  Under OS/2**, the exceptions generated by the
processor are classified as either system exceptions or user
exceptions, with system exceptions being handled by the operating
system, while user exceptions can be handled by the application.  If
the application does not handle a user exception, the operating
system terminates the process that caused the exception.

      Under OS/2, level 1.x, a general protection fault was always
fatal to the process, since such a fault was treated as a system
exception.  Under this condition, a task as conceptually simple as
parameter validation was virtually impossible to accomplish.
Applications were ultimately dependent on their interfaces to provide
valid addresses.  When a general protection fault occurred, all
related processes could also be severely affected, since the
terminated process may have left interprocess resources in
intermediate states.

      On the other hand, OS/2, level 2.0 provides a portable,
system-independent exception architecture, with general protection
faults being treated as user exceptions known as access violations.
The application is thus allowed to handle, and/or repair any access
violations that it generates.  This is accomplished by invoking all
exception handlers along a stack-based chain of registration records
whenever a user exception occurs.  Should none of the registered
procedures handle the exception, the usual default action is provided
by the operating system.

      With the means to validate parameters being thus made
available, a mechanism for handling the validation quickly and
efficiently is needed.  This is particularly important since
exception handlers may be implemented on a per-routine basis.

      A first method for accomplishing this includes reading, an
input or output parameter, and writing for an output parameter, the
first and last bytes accessible in the block referenced by each
address while the handler is installed.  However, this method expands
the normal execution path by requiring several reads and writes over
the normal requirements of the routine.  Also, if the handler is
uninstalle...