Google
 

Trailing-Edge - PDP-10 Archives - bb-bt99h-bb - alg10b.d12
There is 1 other file named alg10b.d12 in the archive. Click here to see a list.
                 EDIT DESCRIPTIONS FOR ALGOL-10-V10B                            
  
  
                             EDIT 362    FOR ALGOL
  
  
  
  
[SYMPTOM]
  
INPUT and OUTPUT procedures accept null device names.
  
  
[DIAGNOSIS]
  
Null device names are not legal.  ALGLIB knows this, but  expects  the
ALGOTS  routine  to detect it by getting an error from the DEVCHR UUO.
However, when ALGOTS passes the null name to DEVCHR, DEVCHR thinks  it
is  a  channel  number  (channel  0).   If  a  device has already been
assigned to channel 0, the DEVCHR returns the characteristics for that
device and no error occurs.
  
  
[CURE]
  
In ALGLIB procedure INPUT/OUTPUT, check for a null name.   If  one  is
found, produce a fatal error.
********************************************************************************
  
  
                             EDIT 363    FOR ALGOL
  
  
  
  
[SYMPTOM]
  
Incorrect PC and line number reported  on  a  runtime  error
message,   dealing   with   mismatched   formal  and  actual
parameters in a procedure call.  Occasional  illegal  memory
references when trying to DUMP variables afterward.
  
[DIAGNOSIS]
  
Incorrect PC/line number:
The code introduced at ERRM2:  by edit 242 is correct if and
only  if  the  error  being reported is "incorrect number of
parameters." For any other error, the wrong  PC  (and  hence
the  wrong  line  number) would be reported.  The "incorrect
number of parameters" error had been generating an incorrect
line  number,  but  edit  242  erroneously  fixed  the error
reporting code rather than the error detecting code.
  
Ill mem ref:
The error reporting code in ALGOTS (ERRMNX et al) and ALGDDT
(HSTPRT) assumes (not unreasonably) that the display pointed
to by DL is properly set up.  If  the  error  occurs  during
parameter  evaluation  (PARAM,  PAR0),  however, this is not
necessarily true.  Since the display contains information on
how  to access variables, if it isn't completely set up then
DUMP will either report garbage or ill mem ref.  PARAM  must
insure  that a sufficiently good DL and %DDTDL are available
to the error reporting code and ALGDDT whenever an error may
be reported.  Edit 202 tried to do something about this, but
wound up confusing things instead.
  
Finally, HSTPRT was prematurely saving  DL,  before  it  had
determined  that  DL  was in fact the correct context.  This
contributed to the ill mem ref problem.
  
Although these two problems seem to be distinct, they are in
fact  related  by  the  environment  in  which  the error is
reported.  In both cases the problem may be traced (directly
or  indirectly)  to  an  inconsistent or incomplete display.
This is primarily the fault of PARAM, which is entirely  too
eager to report errors.
  
[CURE]
  
The patch has the following effects:
  
      o  PARAM now waits until the overhead portion  of  the
         new  DL  is  established  before  trying  to detect
         errors.  In particular, PRGLNK(DL) must be  set  up
         before error reporting will work properly.
  
      o  PARAM now puts off setting up a  new  %DDTDL  until
         all  parameters  have  been evaluated.  %DDTDL must
         point to a complete context, and DL does not  until
         after all parameters are evaluated.
                                                      Page 2
  
  
      o  Replaces  edit  242  with  code  which   looks   in
         PRGLNK(DL)  for the address of the subroutine call.
         With the changes to PARAM, this  should  always  be
         set up.
  
      o  Removes edit 202.
  
      o  Keeps HSTPRT from setting  up  %DDTPC  prematurely.
         This had been allowing context to be established at
         an incomplete display level.
  
With  this  patch  installed,  an  error  during   parameter
evaluation will have the new procedure's DL set up, although
incomplete, for proper error location reporting;   and  will
have  the old display addressed by %DDTDL, where ALGDDT will
find a complete display for use in debugging safely.
********************************************************************************
  
  
                             EDIT 364    FOR ALGOL
  
  
  
  
[SYMPTOM]
  
After an "EXPRESSION TOO LONG" error the Algol compiler  may
spuriously  fail in any of a number of ways, including:  ill
mem ref;  infinite  loop;   UNDEFINED  LABEL  messages  with
garbage labels.
  
[DIAGNOSIS]
  
Algol detects "EXPRESSION TOO LONG" by reaching the  end  of
tempcode  (comparing  INDEX  to TCMAX).  That may not be the
last time INDEX is incremented, however.  If INDEX increases
past TCMAX, part of the symbol table as well as STBB may end
up trashed.
  
[CURE]
  
Whenever tempcode overflows, reset it to empty.
********************************************************************************
  
  
                             EDIT 365    FOR ALGOL
  
  
  
  
[SYMPTOM]
  
Ill mem refs or heap consistency errors after edit  356  has
been  installed  (autopatch  tape 9).  Parts of the heap and
the program may be written over  with  garbage.   Heap  free
list (%SYS2(DB)) is junk.
  
[DIAGNOSIS]
  
Edit 356 incorrectly added an entry, %SYS18, into the middle
of  the  runtime  database.   Since  the  compiler sometimes
generates code which accesses the database, this could cause
programs  compiled  previously to sometimes access the wrong
entry  in  the  database;    in   particular,   instead   of
decrementing the dynamic procedure level, some programs will
decrement the pointer into  the  trace  window.   Since  the
trace  window  is  the first item on the heap, when it wraps
around (with the wrong pointer) it will start  writing  over
the  heap  free  list,  with  devastating results.  The heap
consistency checker will detect this, if  it  is  turned  on
(FTGETCHK=1 in ALGOTS).
  
[CURE]
  
Install edit 356 if not  already  installed.   Then  install
edit  365.   This  moves  %SYS18 to the end of the database.
Once the patch  is  installed,  rebuild  both  the  OTS  and
compiler.   Then  recompile any programs compiled while edit
356 alone was in effect.
********************************************************************************
  
  
                             EDIT 366    FOR ALGOL
  
  
  
  
[SYMPTOM]
  
Overlaid programs run out of memory after switching back and
forth between overlay branches several times.
  
[DIAGNOSIS]
  
When OVRLAY brings in a new overlay branch, it calls  FUNCT.
with  the "Cut Back Core" function in an attempt to keep the
low seg as small as possible.  ALGOTS has no real  mechanism
for  actually  shrinking  the  low  seg;   instead, ALGOTS's
response to the "Cut Back Core" function  of  FUNCT.  is  to
move  the  overlay  free  list in with the normal free list.
This  can  have  an  unwanted  side  effect  of   increasing
fragmentation  (instead  of  reducing  it)  since subsequent
requests for normal heap may be fulfilled  from  the  memory
that  OVRLAY  wants.   OVRLAY's  attempts  to free the space
(e.g.  by moving the symbol table) obviously won't work, and
eventually the program runs out of room.
  
[CURE]
  
Make FNCCBC (the "Cut Back Core" function of FUNCT.) into  a
no-op.  This causes the two heaps (overlay and normal) to be
eternally   separate,   but    won't    actually    increase
fragmentation  noticeably (since OVRLAY usually wants memory
in  specific  places  where  the  normal  heap  wouldn't  go
anyway).   Also  modify  the  heap integrity checker to deal
with the FUNCT. free list as well as the normal free list.
  
Note that fragmentation may still  increase  slightly  as  a
result  of  this patch;  any memory allocated to FUNCT. with
FNCCOR (core anywhere) from the normal heap will be returned
to the overlay free list, not the normal free list.  This is
a rare event, however, so is a far less significant problem.
  
Edits 326 and 361 must be installed first.
********************************************************************************
  
  
  
END OF  ALGOL-10-V10B