Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp

:

more options
 

hp.com home
End of Jump to page title
[DEC PL/I] ALLOCATE Fails To Signal AREA, Sets A Bad Pointer
Jump to content



» 

business support center

Home & Home Office Support:
» HP branded products
» Presario branded products
» Services & Warranties
Small & Medium Business Support:
» Small & Medium Business products
» Small & Medium Business services
Support for IT Professionals:
» Enterprise products (IT Resource Center)
» NonStop enterprise products
» Business & IT Services
Content starts here
Copyright (c) Digital Equipment Corporation 1995.  All rights reserved.

PRODUCT:  DEC PL/I, Version 4.0-5

OP/SYS:   OpenVMS Alpha, Version 6.1

SOURCE:   Digital Equipment Corporation


SYMPTOM:

When there is not enough contiguous memory available in a fragmented
area for the statememts

    ALLOCATE based_item IN(area)

or

    ALLOCATE based_item IN(area) SET(pointer);

to succeed, the PL/I run-time library is supposed to signal the AREA
condition.  In fact, it does so on OpenVMS VAX systems.  But on
OpenVMS Alpha systems the pointer is assigned an invalid address not
within the area and no condition is signaled.


DIGITAL RESPONSE:

This problem has been acknowledged by Engineering, and they plan to
address it in a future version of DEC PL/I for OpenVMS Alpha.


ANALYSIS:

The following test program will reproduce the problem.

 areatest : procedure options(main);
     dcl a area(1100);
     dcl p(10) pointer;
     dcl i fixed binary(31);
     dcl q pointer;
     dcl big char(100) based;
     dcl bigger char(150) based;

     on area
     begin;
         put skip edit('The AREA condition was signaled; resignaling.')(a);
         call resignal();
     end;

     put skip edit('a is at ', encode(int(addr(a)), 16))(a,a);
     a = empty();
     do i = 1 to 10;
         allocate big in(a) set(p(i));
         put skip edit('p(', i, ') = ', encode(int(p(i)), 16))(a,f(2),a,a);
     end;

     free p(1)->big in(a);
     free p(3)->big in(a);
     free p(5)->big in(a);
     free p(7)->big in(a);
     free p(9)->big in(a);

     q = NULL();
     put skip edit('q = ', encode(int(q), 16))(a,a);
     allocate bigger in(a) set(q);
     put skip edit('q = ', encode(int(q), 16))(a,a);

 end areatest;


Session on OpenVMS VAX V6.1 with VAX PL/I V3.5-124:

$ pli areatest
$ link areatest
$ run areatest

 a is at 7FE2EAF8
 p( 1) = 7FE2EB0C
 p( 2) = 7FE2EB74
 p( 3) = 7FE2EBDC
 p( 4) = 7FE2EC44
 p( 5) = 7FE2ECAC
 p( 6) = 7FE2ED14
 p( 7) = 7FE2ED7C
 p( 8) = 7FE2EDE4
 p( 9) = 7FE2EE4C
 p(10) = 7FE2EEB4
 q = 0
The AREA condition was signaled; resignaling.
%PLI-F-AREA, PL/I AREA condition.
-PLI-I-AREA_FULL, No room for variable allocation in area at address 7FE2EAF8.
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC
                                                           00023C65  00023C65
AREATEST        AREATEST                           30      000003D0  0000084C
%PLI-S-FINISH, PL/I Program FINISH condition.


Session on OpenVMS Alpha V6.1 with DEC PL/I V4.0-5

$ pli areatest
$ link areatest
$ run areatest

 a is at 7F8F7648
 p( 1) = 7F8F765C
 p( 2) = 7F8F76C4
 p( 3) = 7F8F772C
 p( 4) = 7F8F7794
 p( 5) = 7F8F77FC
 p( 6) = 7F8F7864
 p( 7) = 7F8F78CC
 p( 8) = 7F8F7934
 p( 9) = 7F8F799C
 p(10) = 7F8F7A04
 q = 0
 q = E0           <- using this pointer will result in an access violation



buy online or call 1.800.AT.COMPAQ
privacy statementusing this site means you accept its terms